This isn't exactly a convincing argument. The HTTP specification explicitly supports caching. On a protocol level, this is quite acceptable and standard. The method I am using is precisely what ISP's do in scenarios where they want to maximize their bandwidth.
On Fri, Jan 9, 2015 at 8:12 PM, Drake Wilson <[email protected]> wrote: > eric gisse wrote: >> Why? People say 'DO NOT MESS WITH TRAFFIC' but in the same breath they >> say 'BUT USE A CACHING DNS RESOLVER'. > > Because the interface level at which exit traffic proper occurs is TCP, > and the interface contract for the client is that the TCP stream will be > direct to the intended destination. The interface level at which > Tor-traversing DNS requests occur is DNS, and the interface contract for > the client is that the DNS request will be resolved in some way that > reflects the consensus public DNS on the Internet. Using a DNS cache is > consistent with being expected to terminate DNS. Using an HTTP cache is > not consistent with being expected to terminate TCP. Reblocking at the > TCP level presumably happens, for instance, and is not considered "messing > with traffic" because it's not specified that Tor passes arbitrary IP > packets, only TCP (and I'm not sure it even requires _full_ TCP other than > the bidirectional octet streams; I forget whether the urgent marker is > passed through, for instance). > > So it's not inconsistent to hear those for exit operators WRT Tor's design. > If you think the design is flawed, that's a separate matter. > > ---> Drake Wilson > > _______________________________________________ > tor-relays mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
