Jure Koren wrote at 2003-11-1 18:38 +0100:

... I do this using calls to RESPONSE.write().

However, I've found out that it is impossible to use the dtml-var tag in any dtml method i call from this python script.

For example, in dtml method fetch_header i call this: <dtml-var standard_html_header>

And I call fetch_header from fetch python script like this: response.write(context.fetch_header(client=context, REQUEST=request))

This looks correct and should work (provided, you defined "request").

If I remove the <dtml-var> and replace it with what the standard_html_header dtml method contains, it works. If there is a dtml-var tag, it breaks, and when it happens, the connection to the browser is closed immediately, and since using streaming mode by calling RESPONSE.write() does not allow raising exceptions, I don't know what is failing. There is no useful debugging information stored anywhere that I know of. No exceptions are raised, or if they are, dtml-try and try:... except: don't catch them.

Provided, you are using Zope 2.6.x (or later), you may see something in "/error_log" (in your Zope "Root Folder") If this does not help, replace the "response.write" with a "return".

Is there a document describing the behaviour of zope using this RESPONSE.write() technique, with explanations of what parts of zope are safe to use in this mode, and when?

It is not documented thoroughly, but it does the obvious: If not yet done, it emits the response header and body collected so far and then its argument. Note, that "HTTP 1.1" requires a correct "Content-Length" for "Keep alive" connections. When "Content-Length" is not yet set, Zope computes the "Content-Length" from the information it knows so far. Usually, this is wrong for "RESPONSE.write". This may be a good reason why the browser ends the response prematurely. Use a TCP logger (e.g. Shane's "tcpwatch") to check the HTTP response headers. -- Dieter