[Edbrowse-dev] Unwind

[Edbrowse-dev] Unwind

[Karl Dahlke]

The interesting part of moving these downloads to a background child process
is that we have already started the curl download,
and somehow we have to stop it in the parent and keep it going in the child,
all from a callback function.
In the parent, after the fork,
I could setjmp back up the stack, I know how to do it,
but as ANA said in A Taste of Armageddon,
"It would frighten any sane man."
Who knows what sort of curl states would be left about.
So I return -1 from the callback function,
and hope curl unwinds the stack properly, *without*
aborting the transfer on the server side.
So far, for ftp and http, it does.
Have not tested ftps, sftp, or tftp.
The secure ones might be an issue, and similarly for https, also untested.
A future version of curl *might* act differently,
and tell the server to hang up, and then this design won't work.
for now, ftp and http work.
I may have to manufacture tests for ftps and https,
unless someone knows of some handy secure download sites on the net.

Another suboptimal consequence, that we can't do anything about,
is that you can't dawdle when asked for a file name.
The curl download is already in progress, and the server side could well time out
if it takes you two minutes to decide where to put the file.
Fortunately, most people will take the default file name provided by the server,
or type in a quick temp file name to go to the download directory
and then move it later.
That's fine.
I suppose I could test the limits, how long can I delay,
at least here with my local servers apache and vsftpd.

Karl Dahlke

Re: [Edbrowse-dev] Unwind

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

On Mon, Dec 29, 2014 at 11:55:10PM -0500, Karl Dahlke wrote:
> > large iso image through ssl
> > https://archive.torproject.org/amnesia.boum.org/tails/stable/tails-i386-1.2.2/tails-i386-1.2.2.iso
> 
> And indeed, it doesn't work, which is what I feared.
> I suppose something in the disconnect process from the parent disrupts
> the ssl connection so that the child cannot continue.
> The error is:
> 
> could not read the data from the server

Ah ok, I'm not entirely surprised. It could be a number of things,
but tbh I suspect that it's going to be difficult to get this to work.
Why don't you do a head request before the get? That way you would get just the headers and could prompt the user and possibly fork before beginning the download?
I suspect this is the cleanest design without getting into multi-threading.
Although it adds an extra round-trip, it'll probably not be that noticeable (if at all).

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] Unwind

[Karl Dahlke]

> large iso image through ssl
> https://archive.torproject.org/amnesia.boum.org/tails/stable/tails-i386-1.2.2/tails-i386-1.2.2.iso

And indeed, it doesn't work, which is what I feared.
I suppose something in the disconnect process from the parent disrupts
the ssl connection so that the child cannot continue.
The error is:

could not read the data from the server

I may have to wait til Chris returns from whereverland,
as he knows a lot more about curl than I do.

This is really tacky, but it would probably work again if I vectored
through an http proxy.
That's not a solution, but would be an interesting test.

Karl Dahlke