[Edbrowse-dev] curl things

[Edbrowse-dev] curl things

[Karl Dahlke]

Welcome back from wherever, and hope you had a grand time.
We have missed your thoughts and advice and wisdom,
but have pressed on anyways.
Your git pull will have a lot of fast forwarding to do.
Read through all our emails and you'll see where we are.
Do make comments on what we have done so far.

> I have plenty of time, and I'm happy to work on this.

That's great news.

As you see, download in the background works for http and ftp,
but not their secure versions,
due to some kind of curl interruptus.
This is the failure case.
https://archive.torproject.org/amnesia.boum.org/tails/stable/tails-i386-1.2.2/tails-i386-1.2.2.iso
Not sure the best plan - maybe (the easy way) I can just return
something different from callback and it will do what I want,
or I can just close the socket in parent before returning -1,
then whatever curl does will not disrupt the server
and what it is doing with the child.
Or maybe the roles of parent and child must switch, if ssl
uses the process id somewhere and must march along.
Uglier cases are to abort and restart the secure download,
or forget about doing it in the background and just download to disk,
which is valuable in itself.
Or just put plain downloads in background, as almost all of them are plain,
and keep secure in foreground, but that could be confusing.
IDK

The most important step in imap might be a clean command line
interface to same, that is not far different from the one in fetchmail.
Don't know a lot about imap, or curl's support thereof,
but would probably like it if it was there.

My next project, which is not a major redisign,
but more like filling in some holes,
is to fix tag.innerHTML = "foobar", in js.
This never really worked properly, never.
It injects html into the page, after it is parsed,
but my parsing software in html.c was built to be a one time thing,
so there is some work to do here.
I use to get around this by dumping the injected html into another buffer
and rendering it there, but that is ugly.
It belongs where it belongs, under the specified tag
on the current page.
And for calls to document.write() after browse, I use to do the same thing,
dump the html somewhere else and parse it in a separate window.
This is illustrated by line 3 in browsed jsrt, the timer, fire it and
watch what it does, ugly.
It should just append that (rendered) html to the current buffer.
Both issues are related, and I am making a series of small foundational
changes that will let me approach this one.

Karl Dahlke

[Edbrowse-dev] multi-pass html rendering

[Adam Thompson]

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

On Sat, Jan 03, 2015 at 10:34:02AM -0500, Karl Dahlke wrote:
> My next project, which is not a major redisign,
> but more like filling in some holes,
> is to fix tag.innerHTML = "foobar", in js.
> This never really worked properly, never.
> It injects html into the page, after it is parsed,
> but my parsing software in html.c was built to be a one time thing,
> so there is some work to do here.
> I use to get around this by dumping the injected html into another buffer
> and rendering it there, but that is ugly.
> It belongs where it belongs, under the specified tag
> on the current page.
> And for calls to document.write() after browse, I use to do the same thing,
> dump the html somewhere else and parse it in a separate window.
> This is illustrated by line 3 in browsed jsrt, the timer, fire it and
> watch what it does, ugly.
> It should just append that (rendered) html to the current buffer.
> Both issues are related, and I am making a series of small foundational
> changes that will let me approach this one.

That's good. It'll be nice to get this sorted,
and hopefully it may make some things work more as expected (I'm not sure what
currently happens if js expects the inner html to be present in the current
page, but that'll no longer be an issue hopefully).

What kind of "foundational changes" are being made,
and will the multi-pass rendering logic be able to also handle other js-made
dom changes or is it going to be more like altering the html string in memory
then re-rendering that?
In addition, will the dom be altered by the presence of this html whilst the script is
running or will the script run then the new html be parsed and linked in?
I'd think the first is the expected behavior, but I'm not sure.

Cheers,
Adam.

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

Re: [Edbrowse-dev] curl things

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> As you see, download in the background works for http and ftp,
> but not their secure versions,

That's strange.  The example works just fine for me.
Usually, when I've seen the "cannot read data from the server" message,
it indicates that the server closed the connection prematurely.  More
often than not, it's just an intermittent failure.  Give it another go
and tell me if it still fails for you.  If it does, libcurl is behaving
differently between versions or something, and it's going to be fun to
track down.

-- Chris

Re: [Edbrowse-dev] curl things

[Adam Thompson]

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

On Mon, Jan 05, 2015 at 10:12:24AM -0800, Chris Brannon wrote:
> Karl Dahlke <eklhad@comcast.net> writes:
> 
> > As you see, download in the background works for http and ftp,
> > but not their secure versions,
> 
> That's strange.  The example works just fine for me.
> Usually, when I've seen the "cannot read data from the server" message,
> it indicates that the server closed the connection prematurely.  More
> often than not, it's just an intermittent failure.  Give it another go
> and tell me if it still fails for you.  If it does, libcurl is behaving
> differently between versions or something, and it's going to be fun to
> track down.

Ok, just got round to testing this and it seems to work for me also.
Out of interest, is there any way we could have a command to tell you what
downloads are currently in progress?

Cheers,
Adam.

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