[Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]

[Oliver Bleutgen]

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 <timhoffman@cams.wa.gov.au> 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