uploads aren't cancelled by closing the web page

[zooko]

As described in #950 (upload doesn't appear in the Recent Uploads Downloads page), I started a large upload and then closed the tab. Later I discovered that the upload was still running (by using flogtool tail on the gateway).

[davidsarah]

This could be implemented using an onbeforeunload handler. That should catch navigating away from the upload tab by any method, as well as closing it (see ​http://www.4guysfromrolla.com/demos/OnBeforeUnloadDemo1.htm for a demo).

The upload operation would need to return an ophandle so that it can be referenced by a cancel operation.

[zooko]

This is related to #1032 (Display active HTTP upload operations on the status page), #952 (multiple simultaneous uploads of the same file) and #320 (add streaming (on-line) upload to HTTP interface).

[zooko]

It was impulsive of me to put this ticket into the 1.8 Milestone. We have enough other important issues in front of us.

[warner]

Hm, I don't know which case this is about:

• if the browser drops the TCP connection before the HTTP body has made it to the gateway, that should clearly stop doing work as soon as the connectionLost is received. There should not be an error in the logs, although it'd be ok if we emitted a one-line warning (perhaps log.UNUSUAL, but not log.WEIRD)
• if the browser successfully gets the HTTP body to the gateway, but then disconnects while the gateway-to-server upload is still running: hm, good question. I'm inclined to think we should process the upload to completion, even though there's no longer a channel to deliver the filecap to the user. This would let their next attempt short-circuit (shares are already present on the grid) and finish faster.

[warner]

Zooko explained to me on IRC (and in #950) that it's the second case. I think it'd be a bit gratuitous to terminate the upload just because they disconnected, but it's predictable and understandable, so I can go along with it.

This probably needs a request.notifyFinish(cb) on the web side, and a bunch of new .cancel code on the Uploader side. Our current interface just returns a Deferred, and doesn't have any sort of "upload-in-progress" handle. Maybe the new "cancellable Deferred" code in recent Twisteds could simplify this? like:

d = do_upload(body)
request.notifyFinish(d.cancel)

[warner]

.. and d.cancel() appeared in Twisted-10.1, which just so happens to be the version we're already requiring (for FTP async close). So the trick will be in adding cancel functionality to the Uploader (probably a flag that gets checked after each segment, just like for the downloader), and use finish_d = Deferred(cancel=self.setCancelFlag)

[davidsarah]

If the file upload is to a mutable file, then the client already has the cap, and so the operation should complete in the second case. (The client has successfully submitted the new contents. Not sticking around to confirm that the publish succeeded is careless, but arguably not incorrect.)

So, do we want mutable and immutable file uploads to behave differently? I would say not, and therefore I would suggest closing this as wontfix, assuming the first case in comment:6 works as intended.