Re: URL field / Loading page images / Refreshing DNS cache

Jorge Arellano Cid <[email protected]>
Newsgroups gmane.comp.web.dillo.devel
Message-ID <[email protected]>
On Fri, Jul 08, 2016 at 05:22:48PM +0200, Johannes Hofmann wrote:
> On Wed, Jul 06, 2016 at 10:28:04AM +0200, Johannes Hofmann wrote:
> > On Tue, Jul 05, 2016 at 04:53:45PM -0400, John Gaffney wrote:
> > > First, a huge thanks to all the Dillo team for their efforts: I just
> > > switched from 3.0.5 to the current snapshot to try out the mbedtls
> > > changes, and I am wowed not only by this, but by all the improvements
> > > in rendering, etc.  Great work!
> > > 
> > > A few suggestions, all very minor, that might be added to the back of
> > > the development queue:
> > > 
> > > In the current snapshot, the navigation bar has changed, and the URL
> > > field does not seem to be taking into account font_factor -- with the
> > > result that the window is smaller than the font height.  You can test
> > > this by setting, e.g., font_factor=2.0 in your dillorc (most
> > > dramatically for a tiny panel with small icons).  The issue seems to
> > > be with this factor not being taken into account when bh and lh are
> > > set in make_panel() in ui.cc.
> > > 
> > > As far as I can see, one can use the context menu to download
> > > individual images on a page, or use the panel to toggle image
> > > loading.  But if one wants not to download images in general, but to
> > > download all the images for some one page (e.g., a weather forecast
> > > page), then one has to toggle downloading of images on and then off
> > > again.  Maybe a command could be added to KeysCommand_t in keys.hh,
> > > bound by default to something like Ctrl-i in keys.cc, with a
> > > corresponding call to a_Html_load_images() in handle() in ui.cc?
> > > 
> > > To make the switch to the current snapshot, I had, sadly, to terminate
> > > an instance of 3.0.5 that had been running continuously for 90 days
> > > without any issues.  But to get that much up time it was necessary to
> > > add a little code so that SIGUSR1 would call a_Dns_freeall() and
> > > a_Dns_init(), otherwise (unless I am missing something) Dillo will
> > > persist in using the cached lookup indefinitely and not detect when
> > > the IP address has changed.  So maybe some sort of key binding could
> > > be added that would flush the cache when needed?
> > 
> > good point. However I'd like to avoid another key-binding and rather
> > do the right thing automatically.
> > I could think of a general DNS entry timeout of a couple of seconds.
> > In many cases DNS responses are cached at OS-level too respecting
> > lifetime values given by the server.
> 
> Firefox has an option to configure the DNS cache expiration
> (network.dnsCacheExpiration).
> Attached patch implements a similar feature for Dillo.

  Thanks for the patch Johannes.

  Under the current workload, I guess I'll look at it in a couple of days.

  BTW, different use cases are very interesting. We usually asume our
use case is generic. Dillo has thaught me several times that's not the
case.

  I for instance, really avoid flushing the DNS cache as it is one of
the slowest parts of my web browsing experience. Sometimes the ISP DNS
server takes more time to answer than the page to load!

  I use another DNS but it's very noticeable, and the sites I usually browse
seldom change their IPs (I've even thought of caching to disk, go figure! ;)

  So I'd like to know what's the use case behind this need. There's surely
something on it (e.g. some site may want to distribute workload between
different servers by changing IP, etc).

  One thing I know DNS queries are abused for is for tracking users.
On the old dialup days, the DNS was very quick to answer, so I suspect
something fishy going on when it takes so much time here on broadband...

-- 
  Cheers
  Jorge.-
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.