Richard Geddes <[EMAIL PROTECTED]> writes: > Seems a little odd that F::Q would fail when advertiser domain names are > unresolvable... I would figure, if an F::Q encounters an ad domain while > scraping, it would ignore it and look for the goodies. I guess I could > tcpdump the F:Q connection to see what's going on at the packet > level... it's been a while since I've tcpdump'ed, so it'll take me some > time to get the output correct.
You're assuming that your "advertiser" host list is both precise and accurate. It may well be neither. Also, as per the mechanism used (changing the resolution for "ad" hosts to "localhost")... when a process encounters a domain, it doesn't know if it's an "ad" domain or not, it just tries to make the connection to localhost, instead, and fails. For HTTP, this will either be a connection failure, or perhaps a 404 or 500 failure (if you happen to be running an http server on your local machine). It just so happens that for the case of an ad image/flash/javascript in common web browsers, these failures result in the desired effect: no advertisement. Other applications might not fail in the same way. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpUJuOtfna0e.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel