> passed the name to the exit node for SOCKS name-to-address resolution Oh, I see, I missed that. For a sec I was thinking it was httpd griping about Host:.
> b) "exoassist" is a bad exit that inserts a web page into the stream returned > to the client when a connection cannot be made. > >That site is in Australia. And considering that that url is down right > >now, and that they're fronting it with squid, who knows what all's > >pooched on their end. Before declaring exo hosed, try it when they're > >back up and by using mapaddress instead. > problem is visible when the destination is down. exoassist is indeed > a bad exit. It should be flagged as such, but still is *not* flagged. I don't think this is either a) the case or b) if so, all that troublesome to warrant a flag. That squid proxy is in AU, either resident on, or in the path between, exo and fibr. Exo certainly has the right to run a cache, hell, lots of people's own upstream ISP's do, transparently. And whoever it is is clearly not munging crap with exploits, just throwing a valid error page. Test Exo with one down and one up site, preferably both not in AU. Separately from that, if it isn't Exo running the cache, which from the hostname it appears it's not, then it's not even Exo's fault. Further, Exo has a contact listed, so why not ask them first before declaring them lame. Tor needs bandwidth, and I'd happily take it through a well configured Squid :) *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/