Christopher N. Deckard wrote: > Oh, and back on the original topic, does anyone know for sure if > the browsers actually send something to the server when "stop" is > pressed?
Yes, it sends a "RST" packet. It ends the tcp-connection. That's why I think throwing an exception when something tries to output data to be served to such a connection is the right thing to do (while it may be not so easy to implement with zope, I don't know). Since the connection is gone, there's no point in accumulating data to be sent back. Tim Hoffman <[EMAIL PROTECTED]> wrote: > Hi > > > Just my 2c worth, > > I wouldn't want this to be a blanket approach if it where ever > implemented. > > If my ZODB is so big that it takes half an hour to rebuild, I would hate > it to be aborted just because the browser lost it's connection (ie IE > crashed ;-) > > or running a big import. I don't need the browser to hang around for the > end result, I just want it to complete at some point. (ie kicking off > long running processes through xml-rpc, I don't want to keep the > connection open for the duration.) I don't know why these examples should be an argument against implementing a saner (just IMO!) policy into zope regarding connection resets. If something like I described would be implemented into zope, it surely should be possible to start an extra thread for doing the stuff you give as an example, or - less desireable IMO - to ignore the connection reset. If this were implemented with an exeption, you just had to catch it and you're done. cheers, oliver _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )