- Dillo-dev - lists.mailman3.com

dillo-2.2-rc1

by corvid＠lavabit.com

As you may have already noticed, we're at RC1 for the next release. Johannes has built a tarball: http://www.dillo.org/download/dillo-2.2-rc1.tar.bz2 SHA1: 146216a1541b20a3e042c62c0db8ee42f173ed01 Please test!

Jan. 31, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Sat, Jan 30, 2010 at 04:13:29AM -0800, bf wrote: > I'm using dillo on FreeBSD 9-CURRENT, and ever since the dpi > framework was converted to use Internet domain sockets, I've been > plagued by long delays when starting dpis because I'm using > blackhole(4) by setting net.inet.tcp.blackhole to be nonzero. An > example of the problem: > > Nav_open_url: new url='dpi:/bm/' > Dpi_check_dpid_ids: Operation timed out > [dpid]: a_Misc_mksecret: e1ab7e05 > Dpi_blocking_start_dpid: try 1 > dpid started > > [...] I understand. Although please notice that it looks as expected behaviour: the check for a responsive dpid socket is delayed just as with any port scan. Simple solution: try something like this script to start dillo: #!/bin/sh ST="`ps -ef|grep "[0-9] dpid"|wc -l`" if [ "$ST" = "1" ]; then echo "Dpid is running OK!" dillo else echo "Dpid is NOT running" dpid & dillo fi -- Cheers Jorge.-

Jan. 30, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by bf2006a＠yahoo.com

I'm using dillo on FreeBSD 9-CURRENT, and ever since the dpi framework was converted to use Internet domain sockets, I've been plagued by long delays when starting dpis because I'm using blackhole(4) by setting net.inet.tcp.blackhole to be nonzero. An example of the problem: Nav_open_url: new url='dpi:/bm/' Dpi_check_dpid_ids: Operation timed out [dpid]: a_Misc_mksecret: e1ab7e05 Dpi_blocking_start_dpid: try 1 dpid started where truss -faedD -s 128 dillo shows: 41523: 12.860150103 0.000110350 write(1,"Nav_open_url: new url='dpi:/bm/'\n",33) = 33 (0x21) 41523: 12.860414941 0.000037435 open("/root/.dillo/dpid_comm_keys",O_RDONLY,0666) = 4 (0x4) 41523: 12.860511880 0.000017599 fstat(4,{ mode=-rw------- ,inode=57842,size=14,blksize=4096 }) = 0 (0x0) 41523: 12.860635080 0.000034920 read(4,"5020 f9097805\n",4096) = 14 (0xe) 41523: 12.860728389 0.000018718 close(4) = 0 (0x0) 41523: 12.860826446 0.000016762 madvise(0x8036a8000,0x1000,0x5,0xfc0,0x2008,0x1) = 0 (0x0) 41523: 12.860962496 0.000029892 socket(PF_INET,SOCK_STREAM,0) = 4 (0x4) 41523: 12.861073963 0.000015086 setsockopt(0x4,0x6,0x1,0x7fffffffe2cc,0x4,0x1) = 0 (0x0) *** long delay here *** 41523: 87.854362496 74.993148012 connect(4,{ AF_INET 127.0.0.1:5020 },16) ERR#60 'Operation timed out' 41523: 87.854777073 0.000028215 stat("/usr/share/nls/C/libc.cat",0x7fffffffdd90) ERR#2 'No such file or directory' 41523: 87.854968159 0.000026260 stat("/usr/share/nls/libc/C",0x7fffffffdd90) ERR#2 'No such file or directory' 41523: 87.855157289 0.000030171 stat("/usr/local/share/nls/C/libc.cat",0x7fffffffdd90) ERR#2 'No such file or directory' 41523: 87.855342508 0.000028774 stat("/usr/local/share/nls/libc/C",0x7fffffffdd90) ERR#2 'No such file or directory' 41523: 87.855672718 0.000116775 write(1,"Dpi_check_dpid_ids: Operation timed out\n",40) = 40 (0x28) 41523: 87.855797315 0.000024026 pipe(0x7fffffffe2e0) = 0 (0x0) 41523: 87.855956274 0.000014248 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGABRT|SIGEMT|SIGKILL|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 41523: 87.867098751 0.011049728 fork() = 41861 (0xa385) 41523: 87.868057253 0.000017321 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 41523: 87.868278789 0.000018158 close(6) = 0 (0x0) 41523: 87.868445291 0.000014806 read(5,0x7fffffffc290,8192) = 0 (0x0) 41523: 87.868540834 0.000016762 madvise(0x8036ed000,0x3000,0x5,0xec,0x6008,0x3) = 0 (0x0) 41523: 87.868635259 0.000017879 close(5) = 0 (0x0) 41523: 87.868838358 0.000086603 write(1,"Dpi_blocking_start_dpid: try 1\n",31) = 41861 (0xa385) 41861: 0.007480839 0.000052800 write(4,"5020 e1ab7e05\n",14) = 14 (0xe) 41861: 0.007616331 0.000027098 close(4) = 0 (0x0) 41861: 0.007730592 0.000027937 socket(PF_INET,SOCK_STREAM,0) = 4 (0x4) 41861: 0.007815798 0.000012851 setsockopt(0x4,0x6,0x1,0x7fffffffe7cc,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.007892903 0.000012013 fcntl(4,F_GETFD,) = 0 (0x0) 41861: 0.007975595 0.000011733 fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) 41861: 0.008087620 0.000020952 bind(4,{ AF_INET 127.0.0.1:5020 },16) ERR#48 'Address already in use' 41861: 0.008303849 0.000017880 bind(4,{ AF_INET 127.0.0.1:5021 },16) = 0 (0x0) 41861: 0.008372573 0.000014248 listen(0x4,0x5,0x10,0x30,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.008458058 0.000019276 socket(PF_INET,SOCK_STREAM,0) = 5 (0x5) 41861: 0.008537677 0.000012012 setsockopt(0x5,0x6,0x1,0x7fffffffe7cc,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.008611709 0.000011733 fcntl(5,F_GETFD,) = 0 (0x0) 41861: 0.008692725 0.000011454 fcntl(5,F_SETFD,FD_CLOEXEC) = 0 (0x0) 41861: 0.008794414 0.000016483 bind(5,{ AF_INET 127.0.0.1:5020 },16) ERR#48 'Address already in use' 41861: 0.008956725 0.000016483 bind(5,{ AF_INET 127.0.0.1:5021 },16) ERR#48 'Address already in use' 41861: 0.009117081 0.000016762 bind(5,{ AF_INET 127.0.0.1:5022 },16) = 0 (0x0) 41861: 0.009184128 0.000013130 listen(0x5,0x5,0x10,0x30,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.009269055 0.000019276 socket(PF_INET,SOCK_STREAM,0) = 6 (0x6) 41861: 0.009348674 0.000011733 setsockopt(0x6,0x6,0x1,0x7fffffffe7cc,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.009422706 0.000011454 fcntl(6,F_GETFD,) = 0 (0x0) 41861: 0.009503722 0.000011454 fcntl(6,F_SETFD,FD_CLOEXEC) = 0 (0x0) 41861: 0.009616865 0.000016483 bind(6,{ AF_INET 127.0.0.1:5020 },16) ERR#48 'Address already in use' 41861: 0.009778617 0.000016482 bind(6,{ AF_INET 127.0.0.1:5021 },16) ERR#48 'Address already in use' 41861: 0.009939252 0.000016203 bind(6,{ AF_INET 127.0.0.1:5022 },16) ERR#48 'Address already in use' 41861: 0.010118605 0.000016762 bind(6,{ AF_INET 127.0.0.1:5023 },16) = 0 (0x0) 41861: 0.010185932 0.000013131 listen(0x6,0x5,0x10,0x30,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.010271417 0.000019276 socket(PF_INET,SOCK_STREAM,0) = 7 (0x7) 41861: 0.010351595 0.000012013 setsockopt(0x7,0x6,0x1,0x7fffffffe7cc,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.010425906 0.000011454 fcntl(7,F_GETFD,) = 0 (0x0) 41861: 0.010507481 0.000011454 fcntl(7,F_SETFD,FD_CLOEXEC) = 0 (0x0) 41861: 0.010609728 0.000016203 bind(7,{ AF_INET 127.0.0.1:5020 },16) ERR#48 'Address already in use' 41861: 0.010770922 0.000016203 bind(7,{ AF_INET 127.0.0.1:5021 },16) ERR#48 'Address already in use' 41861: 0.010931557 0.000016483 bind(7,{ AF_INET 127.0.0.1:5022 },16) ERR#48 'Address already in use' 41861: 0.011091633 0.000016482 bind(7,{ AF_INET 127.0.0.1:5023 },16) ERR#48 'Address already in use' 41861: 0.011252268 0.000016762 bind(7,{ AF_INET 127.0.0.1:5024 },16) = 0 (0x0) 41861: 0.011319037 0.000013131 listen(0x7,0x5,0x10,0x30,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.011404243 0.000018997 socket(PF_INET,SOCK_STREAM,0) = 8 (0x8) 41861: 0.011484141 0.000012012 setsockopt(0x8,0x6,0x1,0x7fffffffe7cc,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.011558452 0.000011733 fcntl(8,F_GETFD,) = 0 (0x0) 41861: 0.011640027 0.000011454 fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0) 41861: 0.011742275 0.000016203 bind(8,{ AF_INET 127.0.0.1:5020 },16) ERR#48 'Address already in use' 41861: 0.011903748 0.000016483 bind(8,{ AF_INET 127.0.0.1:5021 },16) ERR#48 'Address already in use' 41861: 0.012063824 0.000016203 bind(8,{ AF_INET 127.0.0.1:5022 },16) ERR#48 'Address already in use' 41861: 0.012224179 0.000016482 bind(8,{ AF_INET 127.0.0.1:5023 },16) ERR#48 'Address already in use' 41861: 0.012384256 0.000016483 bind(8,{ AF_INET 127.0.0.1:5024 },16) ERR#48 'Address already in use' 41861: 0.012544611 0.000016482 bind(8,{ AF_INET 127.0.0.1:5025 },16) = 0 (0x0) 41861: 0.012611659 0.000013130 listen(0x8,0x5,0x10,0x30,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.012697424 0.000019556 socket(PF_INET,SOCK_STREAM,0) = 9 (0x9) 41861: 0.012777322 0.000012012 setsockopt(0x9,0x6,0x1,0x7fffffffe7cc,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.012851634 0.000011734 fcntl(9,F_GETFD,) = 0 (0x0) 41861: 0.012932929 0.000011454 fcntl(9,F_SETFD,FD_CLOEXEC) = 0 (0x0) 41861: 0.013034897 0.000015924 bind(9,{ AF_INET 127.0.0.1:5020 },16) ERR#48 'Address already in use' 41861: 0.013196370 0.000016203 bind(9,{ AF_INET 127.0.0.1:5021 },16) ERR#48 'Address already in use' 41861: 0.013356726 0.000016483 bind(9,{ AF_INET 127.0.0.1:5022 },16) ERR#48 'Address already in use' 41861: 0.013517081 0.000016482 bind(9,{ AF_INET 127.0.0.1:5023 },16) ERR#48 'Address already in use' 41861: 0.013677157 0.000016482 bind(9,{ AF_INET 127.0.0.1:5024 },16) ERR#48 'Address already in use' 41861: 0.013837234 0.000016483 bind(9,{ AF_INET 127.0.0.1:5025 },16) ERR#48 'Address already in use' 41861: 0.013997310 0.000016483 bind(9,{ AF_INET 127.0.0.1:5026 },16) = 0 (0x0) 41861: 0.014064078 0.000013130 listen(0x9,0x5,0x10,0x30,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.014149284 0.000018996 socket(PF_INET,SOCK_STREAM,0) = 10 (0xa) 41861: 0.014229183 0.000011733 setsockopt(0xa,0x6,0x1,0x7fffffffe7cc,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.014303773 0.000011733 fcntl(10,F_GETFD,) = 0 (0x0) 41861: 0.014385348 0.000011733 fcntl(10,F_SETFD,FD_CLOEXEC) = 0 (0x0) 41861: 0.014487316 0.000016203 bind(10,{ AF_INET 127.0.0.1:5020 },16) ERR#48 'Address already in use' 41861: 0.014648510 0.000016203 bind(10,{ AF_INET 127.0.0.1:5021 },16) ERR#48 'Address already in use' 41861: 0.014808865 0.000016482 bind(10,{ AF_INET 127.0.0.1:5022 },16) ERR#48 'Address already in use' 41861: 0.014968942 0.000016483 bind(10,{ AF_INET 127.0.0.1:5023 },16) ERR#48 'Address already in use' 41861: 0.015129018 0.000016483 bind(10,{ AF_INET 127.0.0.1:5024 },16) ERR#48 'Address already in use' 41861: 0.015297475 0.000016483 bind(10,{ AF_INET 127.0.0.1:5025 },16) ERR#48 'Address already in use' 41861: 0.015457831 0.000016483 bind(10,{ AF_INET 127.0.0.1:5026 },16) ERR#48 'Address already in use' 41861: 0.015618186 0.000016482 bind(10,{ AF_INET 127.0.0.1:5027 },16) = 0 (0x0) 41861: 0.015685234 0.000013130 listen(0xa,0x5,0x10,0x30,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.015770999 0.000019556 socket(PF_INET,SOCK_STREAM,0) = 11 (0xb) 41861: 0.015851177 0.000012013 setsockopt(0xb,0x6,0x1,0x7fffffffe7cc,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.015925767 0.000011733 fcntl(11,F_GETFD,) = 0 (0x0) 41861: 0.016007342 0.000011733 fcntl(11,F_SETFD,FD_CLOEXEC) = 0 (0x0) 41861: 0.016109310 0.000016203 bind(11,{ AF_INET 127.0.0.1:5020 },16) ERR#48 'Address already in use' 41861: 0.016270783 0.000016482 bind(11,{ AF_INET 127.0.0.1:5021 },16) ERR#48 'Address already in use' 41861: 0.016431139 0.000016204 bind(11,{ AF_INET 127.0.0.1:5022 },16) ERR#48 'Address already in use' 41861: 0.016591494 0.000016482 bind(11,{ AF_INET 127.0.0.1:5023 },16) ERR#48 'Address already in use' 41861: 0.016751850 0.000016483 bind(11,{ AF_INET 127.0.0.1:5024 },16) ERR#48 'Address already in use' 41861: 0.016911926 0.000016482 bind(11,{ AF_INET 127.0.0.1:5025 },16) ERR#48 'Address already in use' 41861: 0.017072282 0.000016483 bind(11,{ AF_INET 127.0.0.1:5026 },16) ERR#48 'Address already in use' 41861: 0.017232637 0.000016482 bind(11,{ AF_INET 127.0.0.1:5027 },16) ERR#48 'Address already in use' 41861: 0.017392993 0.000016762 bind(11,{ AF_INET 127.0.0.1:5028 },16) = 0 (0x0) 41861: 0.017459761 0.000012851 listen(0xb,0x5,0x10,0x30,0x4,0x7fffffffe57c) = 0 (0x0) 41861: 0.017559215 0.000015086 sigaction(SIGCHLD,{ 0x401f70 SA_NOCLDSTOP ss_t },0x0) = 0 (0x0) 41861: 0.017650847 0.000013968 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 41861: 0.017851710 0.000086324 write(1,"dpid started\n",13) = 13 (0xd) The particular example of the problem is in is in src/IO/dpi.c: 463 if (Dpi_read_comm_keys(&dpid_port) != -1) { 464 sin.sin_port = htons(dpid_port); 465 if ((sock_fd = Dpi_make_socket_fd()) == -1) { 466 MSG("Dpi_check_dpid_ids: sock_fd=%d %s\n", sock_fd, dStrerror(errno)); 467 } else if (connect(sock_fd, (struct sockaddr *)&sin, sin_sz) == -1) { 468 MSG("Dpi_check_dpid_ids: %s\n", dStrerror(errno)); Can we change this behavior, here and elsewhere, before the release, to avoid long delays for those who are using blackhole(4) or the equivalent for some added measure of security? Regards, b.

Jan. 30, 2010

.hgignore needs updating?

by corvid＠lavabit.com

furaisanjin wrote: > This is a minor issue but after building dillo, hg status shows this. > > ? test/cookies > > I guess .hgignore needs updating. Fixed.

Jan. 28, 2010

.hgignore needs updating?

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jan 28, 2010 at 06:09:55AM +0000, corvid wrote: > > furaisanjin wrote: > > > 2010/1/28 corvid <corvid(a)lavabit.com>: > > > > Johannes wrote: > > > >> On Wed, Jan 27, 2010 at 07:56:37PM +0000, corvid wrote: > > > >> > furaisanjin wrote: > > > >> > > This is a minor issue but after building dillo, hg status shows this. > > > >> > > > > > >> > > ? test/cookies > > > >> > > > > > >> > > I guess .hgignore needs updating. > > > >> > > > > >> > *looks* > > > >> > Why doesn't dpidc need to be in .hgignore? > > > >> > > > >> It is matched by dpid/dpid. Not sure if that is a bug or feature of > > > >> mercurial. > > > > > > > > I vote bug. Should we put ^ and $ around everything, or something like that? > > > > > > dpidc is part of dillo repository. Was that perl script? > > > > Yeah, I think it used to be a perl script. > > I don't see dpidc in the repository anymore. > > > > Hmmm. I just looked back at the 2.1 release code. It had > > dpid/dpid in .hgignore, but it had > > dpid.[ch], dpid_common.[ch], dpidc in the repository. > > > > .hgignore is only relevant for untracked (not in the repository) > files. Ignored files will not show up in "hg status" output with "?". > You can always add ignored files to the repo explicitely with "hg add". Ah. I wonder why mercurial wants to take any notice of untracked files, anyway.

Jan. 28, 2010

.hgignore needs updating?

by furaisanjin＠gmail.com

Hmm, this is a puzzle but hg status -i shows all ignored files and dpidc can be seen on the list. Regards, furaisanjin

Jan. 28, 2010

.hgignore needs updating?

by Johannes.Hofmann＠gmx.de

On Thu, Jan 28, 2010 at 06:09:55AM +0000, corvid wrote: > furaisanjin wrote: > > 2010/1/28 corvid <corvid(a)lavabit.com>: > > > Johannes wrote: > > >> On Wed, Jan 27, 2010 at 07:56:37PM +0000, corvid wrote: > > >> > furaisanjin wrote: > > >> > > This is a minor issue but after building dillo, hg status shows this. > > >> > > > > >> > > ? test/cookies > > >> > > > > >> > > I guess .hgignore needs updating. > > >> > > > >> > *looks* > > >> > Why doesn't dpidc need to be in .hgignore? > > >> > > >> It is matched by dpid/dpid. Not sure if that is a bug or feature of > > >> mercurial. > > > > > > I vote bug. Should we put ^ and $ around everything, or something like that? > > > > dpidc is part of dillo repository. Was that perl script? > > Yeah, I think it used to be a perl script. > I don't see dpidc in the repository anymore. > > Hmmm. I just looked back at the 2.1 release code. It had > dpid/dpid in .hgignore, but it had > dpid.[ch], dpid_common.[ch], dpidc in the repository. > .hgignore is only relevant for untracked (not in the repository) files. Ignored files will not show up in "hg status" output with "?". You can always add ignored files to the repo explicitely with "hg add".

Jan. 28, 2010

.hgignore needs updating?

by corvid＠lavabit.com

furaisanjin wrote: > 2010/1/28 corvid <corvid(a)lavabit.com>: > > Johannes wrote: > >> On Wed, Jan 27, 2010 at 07:56:37PM +0000, corvid wrote: > >> > furaisanjin wrote: > >> > > This is a minor issue but after building dillo, hg status shows this. > >> > > > >> > > ? test/cookies > >> > > > >> > > I guess .hgignore needs updating. > >> > > >> > *looks* > >> > Why doesn't dpidc need to be in .hgignore? > >> > >> It is matched by dpid/dpid. Not sure if that is a bug or feature of > >> mercurial. > > > > I vote bug. Should we put ^ and $ around everything, or something like that? > > dpidc is part of dillo repository. Was that perl script? Yeah, I think it used to be a perl script. I don't see dpidc in the repository anymore. Hmmm. I just looked back at the 2.1 release code. It had dpid/dpid in .hgignore, but it had dpid.[ch], dpid_common.[ch], dpidc in the repository.

Jan. 28, 2010

.hgignore needs updating?

by furaisanjin＠gmail.com

2010/1/28 corvid <corvid(a)lavabit.com>: > Johannes wrote: >> On Wed, Jan 27, 2010 at 07:56:37PM +0000, corvid wrote: >> > furaisanjin wrote: >> > > This is a minor issue but after building dillo, hg status shows this. >> > > >> > > ? test/cookies >> > > >> > > I guess .hgignore needs updating. >> > >> > *looks* >> > Why doesn't dpidc need to be in .hgignore? >> >> It is matched by dpid/dpid. Not sure if that is a bug or feature of >> mercurial. > > I vote bug. Should we put ^ and $ around everything, or something like that? dpidc is part of dillo repository. Was that perl script? Regards, furaisanjin

Jan. 27, 2010

.hgignore needs updating?

by corvid＠lavabit.com

Johannes wrote: > On Wed, Jan 27, 2010 at 07:56:37PM +0000, corvid wrote: > > furaisanjin wrote: > > > This is a minor issue but after building dillo, hg status shows this. > > > > > > ? test/cookies > > > > > > I guess .hgignore needs updating. > > > > *looks* > > Why doesn't dpidc need to be in .hgignore? > > It is matched by dpid/dpid. Not sure if that is a bug or feature of > mercurial. I vote bug. Should we put ^ and $ around everything, or something like that?

Jan. 27, 2010

.hgignore needs updating?

by Johannes.Hofmann＠gmx.de

On Wed, Jan 27, 2010 at 07:56:37PM +0000, corvid wrote: > furaisanjin wrote: > > This is a minor issue but after building dillo, hg status shows this. > > > > ? test/cookies > > > > I guess .hgignore needs updating. > > *looks* > Why doesn't dpidc need to be in .hgignore? It is matched by dpid/dpid. Not sure if that is a bug or feature of mercurial.

Jan. 27, 2010

.hgignore needs updating?

by corvid＠lavabit.com

furaisanjin wrote: > This is a minor issue but after building dillo, hg status shows this. > > ? test/cookies > > I guess .hgignore needs updating. *looks* Why doesn't dpidc need to be in .hgignore?

Jan. 27, 2010

.hgignore needs updating?

by furaisanjin＠gmail.com

Hi all. This is a minor issue but after building dillo, hg status shows this. ? test/cookies I guess .hgignore needs updating. Regards, furaisanjin

Jan. 27, 2010

dpidc

by jcid＠dillo.org

On Tue, Jan 26, 2010 at 04:39:42PM +0200, Rogut??s Sparnuotos wrote: > Johannes Hofmann (2010-01-26 13:55): > > On Tue, Jan 26, 2010 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > > > On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > > > > Wouldn't that be unusual for it to be in anyone's path? > > > > > > > > > > The idea was to have most dillo-related things in that > > > > > directory. Subdirectories in ~/bin look rare, so lacking a better > > > > > idea it ended in ~/.dillo > > > > > > > > To me, it makes the most sense to put it wherever dillo goes. > > > > > > Yes, I agree. > > > Sorry, I was thinking of the dpis. > > > > > > The user may not have permission to install system-wide, and in > > > that case probably dillo, dpid, and dpidc should be in ~/bin and > > > the dpis in ~/.dillo/dpi. > > > > Do we really need to add special handling for this? > > Normally I would expect binaries in $PREFIX/bin and dpis also in > > $PREFIX/bin or $PREFIX/libexec. > > The user has to use a PREFIX where he has write access of course. > > But then the rest is taken care of by autoconf and friends, no? > > At most, the instructions to build dillo [1] could include suggestions how > to run dillo locally. No more special handling should be needed (autoconf > takes care of this case, yes). > > The instructions could be as scarce as this (hope they are correct): > If you choose to install under a different prefix > (./configure --prefix=dir), note that dillo needs > the binaries dpid, dpidc to be in your $PATH. +1 -- Cheers Jorge.-

Jan. 26, 2010

dpidc

by jcid＠dillo.org

On Tue, Jan 26, 2010 at 06:08:03PM +0000, corvid wrote: > Rogut??s wrote: > > [...] > > P.S. Is everyone comfortable with the colors at dillo.org? The logo is > > nice, but the light background with white text means sore eyes to me. > > I also find it hard to read. > It might even be worth making it plain by default, and having a little > stylesheet to add color. There's a volunteer web site designer working on a new scheme. Let's hope people like it. I'll let you know when he sends me a draft. -- Cheers Jorge.-

Jan. 26, 2010

dpidc

by corvid＠lavabit.com

Rogut?s wrote: > Johannes Hofmann (2010-01-26 13:55): > > On Tue, Jan 26, 2010 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > > > On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > > > > Wouldn't that be unusual for it to be in anyone's path? > > > > > > > > > > The idea was to have most dillo-related things in that > > > > > directory. Subdirectories in ~/bin look rare, so lacking a better > > > > > idea it ended in ~/.dillo > > > > > > > > To me, it makes the most sense to put it wherever dillo goes. > > > > > > Yes, I agree. > > > Sorry, I was thinking of the dpis. > > > > > > The user may not have permission to install system-wide, and in > > > that case probably dillo, dpid, and dpidc should be in ~/bin and > > > the dpis in ~/.dillo/dpi. > > > > Do we really need to add special handling for this? > > Normally I would expect binaries in $PREFIX/bin and dpis also in > > $PREFIX/bin or $PREFIX/libexec. > > The user has to use a PREFIX where he has write access of course. > > But then the rest is taken care of by autoconf and friends, no? > > At most, the instructions to build dillo [1] could include suggestions how > to run dillo locally. No more special handling should be needed (autoconf > takes care of this case, yes). > > The instructions could be as scarce as this (hope they are correct): > If you choose to install under a different prefix > (./configure --prefix=dir), note that dillo needs > the binaries dpid, dpidc to be in your $PATH. Yes, judging from what I can find on web forums, it is common for people to try dillo and not be able to get the dpi stuff to work. And, since they don't want to battle with something when they don't even know whether they like it yet, they give up. Spelling out what is happening (on the website and in README) would be a very good thing, I think. (Plus I personally like to put the pieces of programs under my user's dir manually rather than letting make install do whatever it wants.) I think the requirements are: - dillo and dpidc need to be in the path somewhere. - dpid can be in ~/.dillo/, or in bindir, or in the path - the dpi structure (dpi/[dpi]/... goes under ~/.dillo or libdir/dillo. - dpidrc goes in ~/.dillo or sysconfdir/dillo (And a bit about how dillo finds dpid, and then dpid finds the dpis based on dpidrc and all that...) > P.S. Is everyone comfortable with the colors at dillo.org? The logo is > nice, but the light background with white text means sore eyes to me. I also find it hard to read. It might even be worth making it plain by default, and having a little stylesheet to add color.

Jan. 26, 2010

dpidc

by rogutes＠googlemail.com

Johannes Hofmann (2010-01-26 13:55): > On Tue, Jan 26, 2010 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > > On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > > > Wouldn't that be unusual for it to be in anyone's path? > > > > > > > > The idea was to have most dillo-related things in that > > > > directory. Subdirectories in ~/bin look rare, so lacking a better > > > > idea it ended in ~/.dillo > > > > > > To me, it makes the most sense to put it wherever dillo goes. > > > > Yes, I agree. > > Sorry, I was thinking of the dpis. > > > > The user may not have permission to install system-wide, and in > > that case probably dillo, dpid, and dpidc should be in ~/bin and > > the dpis in ~/.dillo/dpi. > > Do we really need to add special handling for this? > Normally I would expect binaries in $PREFIX/bin and dpis also in > $PREFIX/bin or $PREFIX/libexec. > The user has to use a PREFIX where he has write access of course. > But then the rest is taken care of by autoconf and friends, no? At most, the instructions to build dillo [1] could include suggestions how to run dillo locally. No more special handling should be needed (autoconf takes care of this case, yes). The instructions could be as scarce as this (hope they are correct): If you choose to install under a different prefix (./configure --prefix=dir), note that dillo needs the binaries dpid, dpidc to be in your $PATH. [1] http://www.dillo.org/source.html P.S. Is everyone comfortable with the colors at dillo.org? The logo is nice, but the light background with white text means sore eyes to me. -- -- Rogut?s Sparnuotos

Jan. 26, 2010

dpidc

by Johannes.Hofmann＠gmx.de

On Tue, Jan 26, 2010 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > > Jorge wrote: > > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > > Wouldn't that be unusual for it to be in anyone's path? > > > > > > The idea was to have most dillo-related things in that > > > directory. Subdirectories in ~/bin look rare, so lacking a better > > > idea it ended in ~/.dillo > > > > To me, it makes the most sense to put it wherever dillo goes. > > Yes, I agree. > Sorry, I was thinking of the dpis. > > The user may not have permission to install system-wide, and in > that case probably dillo, dpid, and dpidc should be in ~/bin and > the dpis in ~/.dillo/dpi. Do we really need to add special handling for this? Normally I would expect binaries in $PREFIX/bin and dpis also in $PREFIX/bin or $PREFIX/libexec. The user has to use a PREFIX where he has write access of course. But then the rest is taken care of by autoconf and friends, no?

Jan. 26, 2010

dpidc

by jcid＠dillo.org

On Tue, Jan 26, 2010 at 03:42:44AM +0000, corvid wrote: > Jorge wrote: > > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > > Wouldn't that be unusual for it to be in anyone's path? > > > > The idea was to have most dillo-related things in that > > directory. Subdirectories in ~/bin look rare, so lacking a better > > idea it ended in ~/.dillo > > To me, it makes the most sense to put it wherever dillo goes. Yes, I agree. Sorry, I was thinking of the dpis. The user may not have permission to install system-wide, and in that case probably dillo, dpid, and dpidc should be in ~/bin and the dpis in ~/.dillo/dpi. -- Cheers Jorge.-

Jan. 26, 2010

dpidc

by corvid＠lavabit.com

Jorge wrote: > On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > > Wouldn't that be unusual for it to be in anyone's path? > > The idea was to have most dillo-related things in that > directory. Subdirectories in ~/bin look rare, so lacking a better > idea it ended in ~/.dillo To me, it makes the most sense to put it wherever dillo goes.

Jan. 26, 2010

dpidc

by jcid＠dillo.org

On Mon, Jan 25, 2010 at 03:55:39AM +0000, corvid wrote: > - Why does install-dpi-local put dpidc in ~/.dillo, anyway? > Wouldn't that be unusual for it to be in anyone's path? The idea was to have most dillo-related things in that directory. Subdirectories in ~/bin look rare, so lacking a better idea it ended in ~/.dillo > - Do you think it would be silly to make a little manpage for dpidc? Yes. AFAIS the main use of dpidc is "dpidc stop". The "chat" idea is interesting for testing dpis. I don't remember having implemented it though! :). Once it works in a useful way, a man page may help. > - I'm contemplating making dpidc's exit values distinguish between > the cases of: > 1) Bad usage. Wrong number of args. > 2) I can't find the stuff to communicate with dpid (either because this > the first use of dillo, or the dpi system has been changed). > 3) Connection refused. I think dpid just isn't running right now. > 4) Something is breaking while communicating with dpid. Accurate error messages are certainly welcomed. -- Cheers Jorge.-

Jan. 25, 2010

connection limit (was: display: inline)

by Johannes.Hofmann＠gmx.de

On Mon, Jan 25, 2010 at 06:50:44PM +0900, furaisanjin wrote: > 2010/1/22 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > Connections to proxies are also limited - with the same limit as for > > normal hosts (4 atm). > > > > Please give it a try. If it works out ok we might even consider it > > for the release. > > I'm using the new patch for a few days and it seems that I don't see > the problem. Actually I changed proxy connection limit to 10 and this > may also help with patched Dillo. Good. It's in the main repo now with a configurable connection limit (http_max_conns in dillorc). Regards, Johannes

Jan. 25, 2010

connection limit (was: display: inline)

by furaisanjin＠gmail.com

2010/1/22 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Connections to proxies are also limited - with the same limit as for > normal hosts (4 atm). > > Please give it a try. If it works out ok we might even consider it > for the release. I'm using the new patch for a few days and it seems that I don't see the problem. Actually I changed proxy connection limit to 10 and this may also help with patched Dillo. Regards, furaisanjin

Jan. 25, 2010

dpidc

by corvid＠lavabit.com

- Why does install-dpi-local put dpidc in ~/.dillo, anyway? Wouldn't that be unusual for it to be in anyone's path? - Do you think it would be silly to make a little manpage for dpidc? - I'm contemplating making dpidc's exit values distinguish between the cases of: 1) Bad usage. Wrong number of args. 2) I can't find the stuff to communicate with dpid (either because this the first use of dillo, or the dpi system has been changed). 3) Connection refused. I think dpid just isn't running right now. 4) Something is breaking while communicating with dpid.

Jan. 25, 2010

dpi send cmd error msg (Re: [Dillo-dev] Re: even more cookies SECURITY)

by corvid＠lavabit.com

Jorge wrote: > On Sun, Jan 24, 2010 at 11:04:52AM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > > > > > Do we currently have anything that needs to be > > > > > > fixed/implemented before a release would be sensible? > > > > > > > > > > Not that I remember. The only problem I recall was the error > > > > > message you reported with cookies and later seemed to be working > > > > > somehow. > > > > > > > > a_Dpi_send_blocking_cmd() gets upset when > > > > Dpi_blocking_read() doesn't get anything. > > > > > > > > So in the cookie dpi's srv_parse_tok(), > > > > after the Cookies_set(), I tried putting a > > > > a_Dpip_dsh_write_str(sh, 1, "text"), and > > > > that makes the error msgs go away for me. > > > > > > Sorry for the long time to answer. Here's near 35 Celsius among > > > other things... :-P > > > > > > You're right, there's one end expecting an answer that never > > > comes. Something like the attached patch should be enough. > > > > > > Note that this bug may cause some networking delays depending > > > on how the underlaying OS handles closing the socket when there's > > > a blocking reader (it may try to delay the close). > > > > > > The patch avoids this. > > > > I'm a bit hesitant to return a msg if we don't plan to do anything with it, > > but then if we have to send back something, it does make sense to put some > > information in there... > > That's the canonical way of doing it in DPIP. If the message > sender is not interested in the answer, he can ignore it (as in > this case). This allows for a simpler communication algorithm and > a uniform way of dealing with DPIP messages. > > The patch sends an answer that says whether the cookie was set. > It is easy to extend it to say what happened if the need arises. Committed.

Jan. 24, 2010

dpi send cmd error msg (Re: [Dillo-dev] Re: even more cookies SECURITY)

by jcid＠dillo.org

On Sun, Jan 24, 2010 at 11:04:52AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > > > > Do we currently have anything that needs to be > > > > > fixed/implemented before a release would be sensible? > > > > > > > > Not that I remember. The only problem I recall was the error > > > > message you reported with cookies and later seemed to be working > > > > somehow. > > > > > > a_Dpi_send_blocking_cmd() gets upset when > > > Dpi_blocking_read() doesn't get anything. > > > > > > So in the cookie dpi's srv_parse_tok(), > > > after the Cookies_set(), I tried putting a > > > a_Dpip_dsh_write_str(sh, 1, "text"), and > > > that makes the error msgs go away for me. > > > > Sorry for the long time to answer. Here's near 35 Celsius among > > other things... :-P > > > > You're right, there's one end expecting an answer that never > > comes. Something like the attached patch should be enough. > > > > Note that this bug may cause some networking delays depending > > on how the underlaying OS handles closing the socket when there's > > a blocking reader (it may try to delay the close). > > > > The patch avoids this. > > I'm a bit hesitant to return a msg if we don't plan to do anything with it, > but then if we have to send back something, it does make sense to put some > information in there... That's the canonical way of doing it in DPIP. If the message sender is not interested in the answer, he can ignore it (as in this case). This allows for a simpler communication algorithm and a uniform way of dealing with DPIP messages. The patch sends an answer that says whether the cookie was set. It is easy to extend it to say what happened if the need arises. -- Cheers Jorge.-

Jan. 24, 2010

dpi send cmd error msg (Re: [Dillo-dev] Re: even more cookies SECURITY)

by corvid＠lavabit.com

Jorge wrote: > On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote: > > Jorge wrote: > > > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > > > Do we currently have anything that needs to be > > > > fixed/implemented before a release would be sensible? > > > > > > Not that I remember. The only problem I recall was the error > > > message you reported with cookies and later seemed to be working > > > somehow. > > > > a_Dpi_send_blocking_cmd() gets upset when > > Dpi_blocking_read() doesn't get anything. > > > > So in the cookie dpi's srv_parse_tok(), > > after the Cookies_set(), I tried putting a > > a_Dpip_dsh_write_str(sh, 1, "text"), and > > that makes the error msgs go away for me. > > Sorry for the long time to answer. Here's near 35 Celsius among > other things... :-P > > You're right, there's one end expecting an answer that never > comes. Something like the attached patch should be enough. > > Note that this bug may cause some networking delays depending > on how the underlaying OS handles closing the socket when there's > a blocking reader (it may try to delay the close). > > The patch avoids this. I'm a bit hesitant to return a msg if we don't plan to do anything with it, but then if we have to send back something, it does make sense to put some information in there...

Jan. 24, 2010

dpi send cmd error msg (Re: [Dillo-dev] Re: even more cookies SECURITY)

by jcid＠dillo.org

On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote: > Jorge wrote: > > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > > Do we currently have anything that needs to be > > > fixed/implemented before a release would be sensible? > > > > Not that I remember. The only problem I recall was the error > > message you reported with cookies and later seemed to be working > > somehow. > > a_Dpi_send_blocking_cmd() gets upset when > Dpi_blocking_read() doesn't get anything. > > So in the cookie dpi's srv_parse_tok(), > after the Cookies_set(), I tried putting a > a_Dpip_dsh_write_str(sh, 1, "text"), and > that makes the error msgs go away for me. Sorry for the long time to answer. Here's near 35 Celsius among other things... :-P You're right, there's one end expecting an answer that never comes. Something like the attached patch should be enough. Note that this bug may cause some networking delays depending on how the underlaying OS handles closing the socket when there's a blocking reader (it may try to delay the close). The patch avoids this. -- Cheers Jorge.-

Jan. 23, 2010

connection limit (was: display: inline)

by jcid＠dillo.org

On Sat, Jan 23, 2010 at 09:07:10PM +0100, Johannes Hofmann wrote: > > Rogut??s Sparnuotos : > > > > I have skimmed over hundreds of photos on flickr.com with both, vanilla > > dillo-2.1.1 and dillo-hg+connlimit2, with proxy and without. Browsing > > seems to work fine with all variations (I didn't try to analyze the > > packets), but I had a hard time trying to see the difference: I guess my > > internet connection is too fast and my X server too slow. Since I have > > a good internet connection, the images loaded faster without the patch, > > but sometimes the ones at the top of a page appeared sooner when the patch > > was applied. Openning all the connections at once helps speed by making the wait for connections parallel for all images. This is noticeable with a big network latency. > Yes, that's expected. The purpose of the patch is not to improve > loading speed or user experience, but to play nice with servers and > infrastructure. > Modern sites especially big ones like flickr are well prepared > to handle the load caused by the few dillo users out there. > Nevertheless it's important to use network resources in a sensible > and compliant way. I expect most of the mainstream servers to queue multiple requests and thence serve from their queue as much as they want. Other applications may have trouble with a herd of requests at the same time and hence prefer a connection limit. Pages with hundreds of non-tiny images (e.g. some blogs) may *feel* better with throttled requests; here users see the nice effect of images loading "in order". > > Since dillo and the servers seem to work with unlimited connections, > > perhaps defaulting to a limit of 6 wouldn't hurt? > > Yes, the current limit is certainly debatable. > We could even make it configurable. > Any opinions on this? Configurable with a dillorc option would be welcomed. We could comment suggested values for dialup, low band, broadband, ... > > > > Dillo crashed twice in the beginning of my testing, but I am not sure > > anymore which build it was (because I've applied the gnutls-0.patch at > > first - https seemed to work). I couldn't reproduce the crashes > > afterwards. > > Please keep an eye on potential crashes. > Those need to be ironed out of course. I remember when making the first connection limit patch to have apprehensions on the stop/abort process. This is very complex inside Dillo. If you want to crash-test, try going to pages then pressing stop (or quiting that tab), or opening a new one while the other loads, then aborting the first one. Things like that will make dillo stop, clean and keep going. That's the gist. Thanks for your feedback. -- Cheers Jorge.-

Jan. 23, 2010

connection limit (was: display: inline)

by Johannes.Hofmann＠gmx.de

> Rogut?s Sparnuotos : > > I have skimmed over hundreds of photos on flickr.com with both, vanilla > dillo-2.1.1 and dillo-hg+connlimit2, with proxy and without. Browsing > seems to work fine with all variations (I didn't try to analyze the > packets), but I had a hard time trying to see the difference: I guess my > internet connection is too fast and my X server too slow. Since I have > a good internet connection, the images loaded faster without the patch, > but sometimes the ones at the top of a page appeared sooner when the patch > was applied. Yes, that's expected. The purpose of the patch is not to improve loading speed or user experience, but to play nice with servers and infrastructure. Modern sites especially big ones like flickr are well prepared to handle the load caused by the few dillo users out there. Nevertheless it's important to use network resources in a sensible and compliant way. > > Since dillo and the servers seem to work with unlimited connections, > perhaps defaulting to a limit of 6 wouldn't hurt? Yes, the current limit is certainly debatable. We could even make it configurable. Any opinions on this? > > Dillo crashed twice in the beginning of my testing, but I am not sure > anymore which build it was (because I've applied the gnutls-0.patch at > first - https seemed to work). I couldn't reproduce the crashes > afterwards. Please keep an eye on potential crashes. Those need to be ironed out of course. Thanks for reporting back, Johannes -- Haiti-Nothilfe! Helfen Sie per SMS: Sende UIHAITI an die Nummer 81190. Von 5 Euro je SMS (zzgl. SMS-Geb?hr) gehen 4,83 Euro an UNICEF.

Jan. 23, 2010

connection limit (was: display: inline)

by rogutes＠googlemail.com

Johannes Hofmann (2010-01-21 21:07): > Hi, > > I made some progress on the connection limit stuff. > > On Wed, Jan 20, 2010 at 02:43:17PM +0100, Johannes Hofmann wrote: > > On Wed, Jan 20, 2010 at 08:59:12AM -0300, Jorge Arellano Cid wrote: > > > > > > BTW, is the connection-number-limit patch in the next release? > > > > No, it's not ready yet - unfortunately. We urgently need a connection > > limit, but it needs to be per remote host, as otherwise dillo can > > have all of it's 4 connections open to a slow server and then there > > is no connection left for other servers, e.g. used for other windows > > or tabs. > > The limit is now per remote host, so slow servers don't block > connections to other (faster) ones. > Unfortunately the hash table implementation from lout can't be used, > as http.c is C file. > However the number of hosts to which we have open connections at a > time seems to be quite small (maximum about 4 in my tests), so the > simple list I'm using instead should be ok. > > > We alse might need to make a special case for connections to proxies. > > Connections to proxies are also limited - with the same limit as for > normal hosts (4 atm). > > Please give it a try. If it works out ok we might even consider it > for the release. I have skimmed over hundreds of photos on flickr.com with both, vanilla dillo-2.1.1 and dillo-hg+connlimit2, with proxy and without. Browsing seems to work fine with all variations (I didn't try to analyze the packets), but I had a hard time trying to see the difference: I guess my internet connection is too fast and my X server too slow. Since I have a good internet connection, the images loaded faster without the patch, but sometimes the ones at the top of a page appeared sooner when the patch was applied. Since dillo and the servers seem to work with unlimited connections, perhaps defaulting to a limit of 6 wouldn't hurt? Dillo crashed twice in the beginning of my testing, but I am not sure anymore which build it was (because I've applied the gnutls-0.patch at first - https seemed to work). I couldn't reproduce the crashes afterwards. -- -- Rogut?s Sparnuotos

Jan. 23, 2010

connection limit (was: display: inline)

by Johannes.Hofmann＠gmx.de

Hi, I made some progress on the connection limit stuff. On Wed, Jan 20, 2010 at 02:43:17PM +0100, Johannes Hofmann wrote: > On Wed, Jan 20, 2010 at 08:59:12AM -0300, Jorge Arellano Cid wrote: > > > > BTW, is the connection-number-limit patch in the next release? > > No, it's not ready yet - unfortunately. We urgently need a connection > limit, but it needs to be per remote host, as otherwise dillo can > have all of it's 4 connections open to a slow server and then there > is no connection left for other servers, e.g. used for other windows > or tabs. The limit is now per remote host, so slow servers don't block connections to other (faster) ones. Unfortunately the hash table implementation from lout can't be used, as http.c is C file. However the number of hosts to which we have open connections at a time seems to be quite small (maximum about 4 in my tests), so the simple list I'm using instead should be ok. > We alse might need to make a special case for connections to proxies. Connections to proxies are also limited - with the same limit as for normal hosts (4 atm). Please give it a try. If it works out ok we might even consider it for the release. Cheers, Johannes

Jan. 21, 2010

experimental patch: gnutls for the https dpi

by newman.x＠gmail.com

On Wed, Jan 20, 2010 at 9:01 PM, corvid <corvid(a)lavabit.com> wrote: > Michal wrote: >> On Wed, Jan 20, 2010 at 10:52 AM, corvid <corvid(a)lavabit.com> wrote: >> > A few hours ago, I started to wonder how much trouble it would be to >> > make https.c understand gnutls instead of openssl. >> > >> > The answer is: If you borrow liberally from the public domain code in >> > ? ? ? ? ? ? ? the gnutls manual, then not very much! >> > >> > So here's a toy for anyone who would like one: >> > ?http://www.dillo.org/test/gnutls.0.patch >> >> What about NSS? >> >> https://fedoraproject.org/wiki/FedoraCryptoConsolidation >> >> It might bring even more (FIPS) compared to gnutls. > > Does gnutls lack it because it requires paying $$ and/or infinite > bureaucratic hurdles, or is it a technical matter? Possibility #1: definitely Possibility #2: FWIH, crypto part is easy, mostly eliminating "unsafe" algorithms and it's settings but there might be others not that easy stuff, like centralized cert management, ... > The NSS documentation seems to say that applications would no longer > have to know where a file full of certificates is because that would all > be taken care of by NSS in some centralized thing. Is that the case? I guess so https://fedoraproject.org/wiki/CryptoConsolidationEval#NSS > _That_ would definitely appeal to me. NSS seems to be the future of crypto API, unless it's too heavy-weight for project like Dillo, consider it instead of gnutls. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 21, 2010

dpi send cmd error msg (Re: [Dillo-dev] Re: even more cookies SECURITY)

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > > Do we currently have anything that needs to be > > > fixed/implemented before a release would be sensible? > > > > Not that I remember. The only problem I recall was the error > > message you reported with cookies and later seemed to be working > > somehow. > > a_Dpi_send_blocking_cmd() gets upset when > Dpi_blocking_read() doesn't get anything. > > So in the cookie dpi's srv_parse_tok(), > after the Cookies_set(), I tried putting a > a_Dpip_dsh_write_str(sh, 1, "text"), and > that makes the error msgs go away for me. What if we do the following:

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by corvid＠lavabit.com

Michal wrote: > On Wed, Jan 20, 2010 at 10:52 AM, corvid <corvid(a)lavabit.com> wrote: > > A few hours ago, I started to wonder how much trouble it would be to > > make https.c understand gnutls instead of openssl. > > > > The answer is: If you borrow liberally from the public domain code in > > ? ? ? ? ? ? ? the gnutls manual, then not very much! > > > > So here's a toy for anyone who would like one: > > ?http://www.dillo.org/test/gnutls.0.patch > > What about NSS? > > https://fedoraproject.org/wiki/FedoraCryptoConsolidation > > It might bring even more (FIPS) compared to gnutls. Does gnutls lack it because it requires paying $$ and/or infinite bureaucratic hurdles, or is it a technical matter? The NSS documentation seems to say that applications would no longer have to know where a file full of certificates is because that would all be taken care of by NSS in some centralized thing. Is that the case? _That_ would definitely appeal to me.

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jan 20, 2010 at 09:52:31AM +0000, corvid wrote: > > A few hours ago, I started to wonder how much trouble it would be to > > make https.c understand gnutls instead of openssl. > > > > The answer is: If you borrow liberally from the public domain code in > > the gnutls manual, then not very much! > > > > So here's a toy for anyone who would like one: > > http://www.dillo.org/test/gnutls.0.patch > > Quite interesting. > > AFAIS from the patch it's doing more or less the same as the > current https dpi. It looks like this dpi's certificate handling > code may be easier to complete with GNU TLS. > > What's the motivation for the switch? - It's pleasing to using something GPLed and not have special linking exceptions in the license. - I get the impression that people are starting to look at openssl a little like they did with gtk1 ("How many programs do I have that still require it? Can I get rid of it?")

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by newman.x＠gmail.com

On Wed, Jan 20, 2010 at 10:52 AM, corvid <corvid(a)lavabit.com> wrote: > A few hours ago, I started to wonder how much trouble it would be to > make https.c understand gnutls instead of openssl. > > The answer is: If you borrow liberally from the public domain code in > ? ? ? ? ? ? ? the gnutls manual, then not very much! > > So here's a toy for anyone who would like one: > ?http://www.dillo.org/test/gnutls.0.patch What about NSS? https://fedoraproject.org/wiki/FedoraCryptoConsolidation It might bring even more (FIPS) compared to gnutls. > Now we'll _have_ to have a release soon, because we're accumulating so > many things to play with after release... Michal

Jan. 20, 2010

display: inline

by Johannes.Hofmann＠gmx.de

On Wed, Jan 20, 2010 at 08:59:12AM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 19, 2010 at 08:17:01PM +0100, Johannes Hofmann wrote: > > On Mon, Jan 18, 2010 at 03:40:31PM -0300, Jorge Arellano Cid wrote: > > > On Tue, Jan 12, 2010 at 06:48:19PM +0100, Johannes Hofmann wrote: > > > > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > I started to experiment with the real solution, which means that the > > > > > display member of Style determines whether a (Text)block is created > > > > > or a ListItem, or whether just normal text is added. > > > > > The patch is still small, but as the change is pretty > > > > > fundamental, so I decided to put it in a separate repo for now. > > > > > You can find it at: > > > > > > > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > > > > > > > > > > I've updated this prototype a bit. It works quite well, the only > > > > drawback is the added complexity in html.cc. > > > > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > > > > an optional Html_tag_content_*() function for tags that create > > > > widgets or other content. This function is not called in the > > > > display:none case. > > > > The reason for the splitting into Html_tag_open_*() and > > > > Html_tag_content_*() is that styleEngine->setNonCssHints() is > > > > needed before we can get the current style. > > > > Only after that is done, we know the value of the display property > > > > and can decide whether to call Html_tag_content_*() or not. > > > > > > > > I'd like to get this into main line soon if you agree. > > > > Please let me know what you think. > > > > > [...] > > > > - Please don't merge the IPPROTO_TCP patch with it. > > > > If you mean the TCP_NODELAY stuff, it's in the main repo already. > > Normally the TCP stack waits a little until there is enough data to > > send. This is good for throughput but bad for response time. It is > > especially bad for client server stuff like DPI over local loopback. > > It really slows down pages with cookies. > > But I can back it out if you like. It would no longer be necessary > > when we switch back to UNIX domain sockets anyway. > > OK, leave it then. > > BTW, is the connection-number-limit patch in the next release? No, it's not ready yet - unfortunately. We urgently need a connection limit, but it needs to be per remote host, as otherwise dillo can have all of it's 4 connections open to a slow server and then there is no connection left for other servers, e.g. used for other windows or tabs. We alse might need to make a special case for connections to proxies. Ah, and while at it it might be interesting to look into persistent connections... Cheers, Johannes

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by jcid＠dillo.org

On Wed, Jan 20, 2010 at 09:52:31AM +0000, corvid wrote: > A few hours ago, I started to wonder how much trouble it would be to > make https.c understand gnutls instead of openssl. > > The answer is: If you borrow liberally from the public domain code in > the gnutls manual, then not very much! > > So here's a toy for anyone who would like one: > http://www.dillo.org/test/gnutls.0.patch Quite interesting. AFAIS from the patch it's doing more or less the same as the current https dpi. It looks like this dpi's certificate handling code may be easier to complete with GNU TLS. What's the motivation for the switch? -- Cheers Jorge.-

Jan. 20, 2010

display: inline

by jcid＠dillo.org

On Tue, Jan 19, 2010 at 08:17:01PM +0100, Johannes Hofmann wrote: > On Mon, Jan 18, 2010 at 03:40:31PM -0300, Jorge Arellano Cid wrote: > > On Tue, Jan 12, 2010 at 06:48:19PM +0100, Johannes Hofmann wrote: > > > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > I started to experiment with the real solution, which means that the > > > > display member of Style determines whether a (Text)block is created > > > > or a ListItem, or whether just normal text is added. > > > > The patch is still small, but as the change is pretty > > > > fundamental, so I decided to put it in a separate repo for now. > > > > You can find it at: > > > > > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > > > > > > > I've updated this prototype a bit. It works quite well, the only > > > drawback is the added complexity in html.cc. > > > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > > > an optional Html_tag_content_*() function for tags that create > > > widgets or other content. This function is not called in the > > > display:none case. > > > The reason for the splitting into Html_tag_open_*() and > > > Html_tag_content_*() is that styleEngine->setNonCssHints() is > > > needed before we can get the current style. > > > Only after that is done, we know the value of the display property > > > and can decide whether to call Html_tag_content_*() or not. > > > > > > I'd like to get this into main line soon if you agree. > > > Please let me know what you think. > > > [...] > > - Please don't merge the IPPROTO_TCP patch with it. > > If you mean the TCP_NODELAY stuff, it's in the main repo already. > Normally the TCP stack waits a little until there is enough data to > send. This is good for throughput but bad for response time. It is > especially bad for client server stuff like DPI over local loopback. > It really slows down pages with cookies. > But I can back it out if you like. It would no longer be necessary > when we switch back to UNIX domain sockets anyway. OK, leave it then. BTW, is the connection-number-limit patch in the next release? -- Cheers Jorge.-

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by corvid＠lavabit.com

A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl. The answer is: If you borrow liberally from the public domain code in the gnutls manual, then not very much! So here's a toy for anyone who would like one: http://www.dillo.org/test/gnutls.0.patch Now we'll _have_ to have a release soon, because we're accumulating so many things to play with after release...

Jan. 20, 2010

display: inline

by Johannes.Hofmann＠gmx.de

On Mon, Jan 18, 2010 at 03:40:31PM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 12, 2010 at 06:48:19PM +0100, Johannes Hofmann wrote: > > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > I started to experiment with the real solution, which means that the > > > display member of Style determines whether a (Text)block is created > > > or a ListItem, or whether just normal text is added. > > > The patch is still small, but as the change is pretty > > > fundamental, so I decided to put it in a separate repo for now. > > > You can find it at: > > > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > > > > I've updated this prototype a bit. It works quite well, the only > > drawback is the added complexity in html.cc. > > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > > an optional Html_tag_content_*() function for tags that create > > widgets or other content. This function is not called in the > > display:none case. > > The reason for the splitting into Html_tag_open_*() and > > Html_tag_content_*() is that styleEngine->setNonCssHints() is > > needed before we can get the current style. > > Only after that is done, we know the value of the display property > > and can decide whether to call Html_tag_content_*() or not. > > > > I'd like to get this into main line soon if you agree. > > Please let me know what you think. > > I checked the last repo, and AFAIS it's OK to merge. I agreed with corvid to leave it out until after the release. > > Notes: > > - I agree with corvid on using NULL instead of Html_tag_close_default. Ok. > - There's a comment on *open and *close() function being always > called but there's still a conditional close on display_none. > Please check it. Ok. > - Please don't merge the IPPROTO_TCP patch with it. If you mean the TCP_NODELAY stuff, it's in the main repo already. Normally the TCP stack waits a little until there is enough data to send. This is good for throughput but bad for response time. It is especially bad for client server stuff like DPI over local loopback. It really slows down pages with cookies. But I can back it out if you like. It would no longer be necessary when we switch back to UNIX domain sockets anyway. Cheers, Johannes

Jan. 19, 2010

dillo2.x on Fedora 12

by newman.x＠gmail.com

On Mon, Jan 18, 2010 at 9:17 PM, Globe Trotter <itsme_410(a)yahoo.com> wrote: > Hi, > > Does that mean that Dillo has no hope also because it is based on fltk2? > > Thanks! > T FLTK2 is somewhat dead end from Fedora perspective. There is a bunch of issues in upstream FLTK2 snapshots regarding Fedora package policies. I fixed several of them in Package Review https://bugzilla.redhat.com/show_bug.cgi?id=fltk2 but then lost hope when others appeared... And more, upstream's not willing to fix bugs I found when pushing FLTK2 to Fedora (e.g. they sticked w/ "static" linking). FLTK1.3 (and 1.4) is the way to go, once it's released. I remember, release was scheduled for last summer but postponed. See their mailing list for latest info, they have some 4 items, 2 of them non-trivial, on the list. Michal

Jan. 19, 2010

Cookies performance

by furaisanjin＠gmail.com

2010/1/19 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Do you have a fast or slow internet connection? I have FTTH at home and the connection iself is quite fast. > Do you know what kind of proxy you are connecting to? I'm using this proxy on my machine. <<http://www.acme.com/software/micro_proxy/>> But I modified this to act as daemon and limit the active connection (usually the active connection limit is 4 but proxy itself accepts all connections). I found that my modification for the proxy caused the problem. I had to modify a_Capi_stop_client like this. Client = a_Cache_client_get_if_unique(Key); - if (Client && (force || Client->BufSize == 0)) { + if (Client && force) { /* remove empty entries too */ a_Capi_conn_abort_by_url(Client->Url); After I canceled my modification, downloading didn't stop but I started seeing this kind of warning. ** WARNING **: IO_write, closing with pending data not sent ** WARNING **: "GET http://img.f.hatena.ne.jp/images/fotolife/z/zankuro/20090805/20090805082105… HTTP/1.1\x0D Regards, furaisanjin

Jan. 19, 2010

Cookies performance

by Johannes.Hofmann＠gmx.de

On Mon, Jan 18, 2010 at 06:59:08PM +0100, Johannes Hofmann wrote: > On Mon, Jan 18, 2010 at 03:58:25PM +0900, furaisanjin wrote: > > 2010/1/18 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > Please test attached patch. It limits the overall number of > > > concurrent connections to 4. > > > > I tested this with TCP_NODELAY option and it seems that further image > > downloading stops when the page repush happens due to remote CSS. So I > > don't see all images. Good thing is that I don't get the error > > message. > > Hm, it seems to work ok here... Ok, I'm also seeing an issue now. Not sure if it's the problem you are having. With an overall limit of open connections a slow server can eat up all 4 connections. Then dillo can't connect to other hosts anymore, e.g. in an other window or tab. This needs to be addressed.

Jan. 19, 2010

dillo2.x on Fedora 12

by Johannes.Hofmann＠gmx.de

On Mon, Jan 18, 2010 at 12:17:08PM -0800, Globe Trotter wrote: > > > --- On Fri, 12/18/09, Michal Nowak <newman.x(a)gmail.com> wrote: > > > From: Michal Nowak <newman.x(a)gmail.com> > > Subject: Re: [Dillo-dev] dillo2.x on Fedora 12 > > To: "Globe Trotter" <itsme_410(a)yahoo.com> > > Cc: dillo-dev(a)dillo.org > > Date: Friday, December 18, 2009, 6:26 AM > > On Fri, Dec 18, 2009 at 4:47 AM, > > Globe Trotter <itsme_410(a)yahoo.com> > > wrote: > > > Hi, > > > > > > Any likelihood of getting some Fedora 12 dillo2 RPMS? > > > > > > > You may try > > > > http://mnowak.fedorapeople.org/dillo2/ > > > > should be the last release. There are static RPMs for F-11 > > and SRPM, which > > you can rebuild yourself for F-12, when you have installed > > static FLTK2 > > > > http://mnowak.fedorapeople.org/fltk2/static/ > > > > Though, unlikely to have Dillo 2 in Fedora as a supported > > package due to > > FLTK2, which is used in Dillo 2, is unreleased version, we > > don't wanna in > > Fedora. (Anyway FLTK2 seemed to me dead, last time I've > > looked, anyway.) > > Hi, > > Does that mean that Dillo has no hope also because it is based on fltk2? Definately not. Even though there is only few development going on for fltk2, it works rather well for us and pressing bugs get fixed. We also keep an eye on fltk-1.3 for which there is active development. Once there is an official fltk-1.3 release we will consider whether to switch to that version. Generally in dillo2 there is a pretty good separation of general code and GUI toolkit dependent code, so a port to another toolkit is possible. Cheers, Johannes

Jan. 18, 2010

dillo2.x on Fedora 12

by Johannes.Hofmann＠gmx.de

On Mon, Jan 18, 2010 at 12:17:08PM -0800, Globe Trotter wrote: > > > --- On Fri, 12/18/09, Michal Nowak <newman.x(a)gmail.com> wrote: > > > From: Michal Nowak <newman.x(a)gmail.com> > > Subject: Re: [Dillo-dev] dillo2.x on Fedora 12 > > To: "Globe Trotter" <itsme_410(a)yahoo.com> > > Cc: dillo-dev(a)dillo.org > > Date: Friday, December 18, 2009, 6:26 AM > > On Fri, Dec 18, 2009 at 4:47 AM, > > Globe Trotter <itsme_410(a)yahoo.com> > > wrote: > > > Hi, > > > > > > Any likelihood of getting some Fedora 12 dillo2 RPMS? > > > > > > > You may try > > > > http://mnowak.fedorapeople.org/dillo2/ > > > > should be the last release. There are static RPMs for F-11 > > and SRPM, which > > you can rebuild yourself for F-12, when you have installed > > static FLTK2 > > > > http://mnowak.fedorapeople.org/fltk2/static/ > > > > Though, unlikely to have Dillo 2 in Fedora as a supported > > package due to > > FLTK2, which is used in Dillo 2, is unreleased version, we > > don't wanna in > > Fedora. (Anyway FLTK2 seemed to me dead, last time I've > > looked, anyway.) > > Hi, > > Does that mean that Dillo has no hope also because it is based on fltk2? Definately not. Even though there is only few development going on for fltk2, it works rather well for us and pressing bugs get fixed. We also keep an eye on fltk-1.3 for which there is active development. Once there is an official fltk-1.3 release we will consider whether to switch to that version. Generally in dillo2 there is a pretty good separation of general code and GUI toolkit dependent code, so a port to another toolkit is possible. Cheers, Johannes

Jan. 18, 2010

Cookies performance

by Johannes.Hofmann＠gmx.de

On Mon, Jan 18, 2010 at 06:19:28PM +0000, corvid wrote: > Johannes wrote: > > On Mon, Jan 18, 2010 at 03:58:25PM +0900, furaisanjin wrote: > > > 2010/1/18 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > > Please test attached patch. It limits the overall number of > > > > concurrent connections to 4. > > > > > > I tested this with TCP_NODELAY option and it seems that further image > > > downloading stops when the page repush happens due to remote CSS. So I > > > don't see all images. Good thing is that I don't get the error > > > message. > > > > Hm, it seems to work ok here... > > > > Does loading other pages still work, after image loading has > > stalled, or is the complete dillo instance broken after that? > > > > Do you have a fast or slow internet connection? > > > > Do you know what kind of proxy you are connecting to? > > I've tried with image loading and remote stylesheets on to the > degree that I can tolerate :) , and I like this connection > limiting a whole lot. We definately need a connection limit. Currently dillo can be spawning hundreds of connections to a single server which is not nice. HTTP 1.1 even suggests a limit of 2 connections per host though according to http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/ modern browsers us something between 2 and 6 now, so I think an overall limit of 4 is ok for dillo. There even is a benefit when loading long pages with images: With the connection limit in place the first (and probabely visible) images on the page get more bandwidth and load faster. > > So far, all I've noticed was once getting one of those > "IO_write, closing with pending data not sent" msgs > when I left a page while things were loading. It didn't seem > to cause any harm, though. > This might be connections that get aborted while still queued and therefore not connected. I will check that. Cheers, Johannes

Jan. 18, 2010

dillo2.x on Fedora 12

by itsme_410＠yahoo.com

--- On Fri, 12/18/09, Michal Nowak <newman.x(a)gmail.com> wrote: > From: Michal Nowak <newman.x(a)gmail.com> > Subject: Re: [Dillo-dev] dillo2.x on Fedora 12 > To: "Globe Trotter" <itsme_410(a)yahoo.com> > Cc: dillo-dev(a)dillo.org > Date: Friday, December 18, 2009, 6:26 AM > On Fri, Dec 18, 2009 at 4:47 AM, > Globe Trotter <itsme_410(a)yahoo.com> > wrote: > > Hi, > > > > Any likelihood of getting some Fedora 12 dillo2 RPMS? > > > > You may try > > http://mnowak.fedorapeople.org/dillo2/ > > should be the last release. There are static RPMs for F-11 > and SRPM, which > you can rebuild yourself for F-12, when you have installed > static FLTK2 > > http://mnowak.fedorapeople.org/fltk2/static/ > > Though, unlikely to have Dillo 2 in Fedora as a supported > package due to > FLTK2, which is used in Dillo 2, is unreleased version, we > don't wanna in > Fedora. (Anyway FLTK2 seemed to me dead, last time I've > looked, anyway.) Hi, Does that mean that Dillo has no hope also because it is based on fltk2? Thanks! T > Unless Dillo 2 is based on some released and supported > toolkit, Dillo 2 won't > be Fedora-supported.

Jan. 18, 2010

display: inline

by jcid＠dillo.org

On Tue, Jan 12, 2010 at 06:48:19PM +0100, Johannes Hofmann wrote: > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > Hi, > > > > I started to experiment with the real solution, which means that the > > display member of Style determines whether a (Text)block is created > > or a ListItem, or whether just normal text is added. > > The patch is still small, but as the change is pretty > > fundamental, so I decided to put it in a separate repo for now. > > You can find it at: > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > I've updated this prototype a bit. It works quite well, the only > drawback is the added complexity in html.cc. > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > an optional Html_tag_content_*() function for tags that create > widgets or other content. This function is not called in the > display:none case. > The reason for the splitting into Html_tag_open_*() and > Html_tag_content_*() is that styleEngine->setNonCssHints() is > needed before we can get the current style. > Only after that is done, we know the value of the display property > and can decide whether to call Html_tag_content_*() or not. > > I'd like to get this into main line soon if you agree. > Please let me know what you think. I checked the last repo, and AFAIS it's OK to merge. Notes: - I agree with corvid on using NULL instead of Html_tag_close_default. - There's a comment on *open and *close() function being always called but there's still a conditional close on display_none. Please check it. - Please don't merge the IPPROTO_TCP patch with it. -- Cheers Jorge.-

Jan. 18, 2010