- Dillo-dev - lists.mailman3.com

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