<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jun 22, 2005, at 1:25 PM, Jonathan wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Set up your web page so that it has two frames: the main frame (visable) invokes the long running zope script;<SPAN class="Apple-converted-space"> </SPAN>and a secondary (hidden) frame uses a javascript routine (running on a timer) which queries a no-op zope script. This should stop your browser from timing out.</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Ugly, but it should work.</FONT></P></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I don't think it would. Those two frames would or could be two separate requests. Starting the no-op script is going to have no effect on the entirely separate long running script.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>When I said "would or could", it is because the exact behavior may depend on circumstances but the end result is the same. If Ralph is truly seeing HTTP 1.0 requests, then of course each connection would be independent and the completion of one request isn't going to reset the timeout for the other. In HTTP 1.1, you can combine multiple requests into a single socket connection, but I still don't think it would help. The way I've seen most browsers implement HTTP 1.1 persistent connections, A connection opened for an initial user request (when the user clicks a link or types a new address into the menu bar.) it send requests for the subordinate elements (the "src=" attributes on the returned page) over the persistent connection. Once the initial request (including its subordinate components) is complete the connection is closed. Requests from different windows or different frames tend not to be intermingled within a socket connection. (and even then, do you want to depend on it? The spec says that the browser can send more than one request over a connection, not that it must.) Finally, The HTTP spec doesn't have facilities for out of order execution. You send a request, you get back the result. You send another request, you get back the next result. As soon as the long running request is sent, the "no-op" request will not be responded to.</DIV></BODY></HTML>