[Webkit-unassigned] [Bug 23846] [GTK]Enable DNS prefetching

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=23846





--- Comment #15 from Xan Lopez <xan.lopez at gmail.com>  2009-10-25 12:00:28 PDT ---
> 
> > +    // This may work while soup_session_prepare_for_uri is not avaliable
> > +    SoupAddress* address = soup_address_new(hostname.utf8().data(),
> > +        SOUP_ADDRESS_ANY_PORT);
> 
> No need to break this line, it is not too long by WebKit standards.
> 
> > +    soup_address_resolve_async(address, 0, 0, 0, 0);
> > +    g_object_unref(address);
> 
> According to my understanding of what was said in #webkit-gtk by danw recently,
> on newer libsoup versions this would have no effect. Here's the relevant
> discussion:
> 
> Oct 22 14:11:12 <danw>  xan: pre-GResolver, there was a one hour cache
> underneath SoupAddress, so if you did soup_address_new("google.com"), then that
> might al
> ready be resolved. Post-GResolver, that caching layer is gone. However,
> SoupSession still caches *specific SoupAddresses*. So if you do your own
> soup_address_n
> ew("google.com"), then you're going to have to go to the network to resolve it.
> But if you queue a request for "google.com", SoupSessino probably
> Oct 22 14:11:12 <danw>   already has an already-resolved SoupAddress to use
> 
> We may want to have this for older soup versions, but then again, it may be
> better to queue a NO-OP request? r- for now, for the above. Thanks for working
> on this.

Well, he *is* going to the network to resolve it, right? He explicitly calls
the function to resolve the host :)

That being said, I'd prefer to get whatever code dan thinks is OK to handle
this (like the prepare function mentioned in the comment), and then just use
it. I don't think this is important enough to land workarounds. Also, same
thing for the TTL hashtable, I'd rather have soup handle that automatically if
possible, otherwise everyone using that API will probably do something similar.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.