On Sat, Jun 04, 2011 at 11:15:53PM -0400, Nick Mathewson wrote:
On Thu, Jun 2, 2011 at 8:45 PM, Ian Goldberg iang@cs.uwaterloo.ca wrote:
Sorry this took so long. As usual, things got inserted ahead of it in the priority queue. :-p
Anyway, here's the client-side sibling proposal to the already-implemented 174. It cuts down time-to-first-byte for HTTP requests by 25 to 50 percent, so long as your SOCKS client (e.g. webfetch, polipo, etc.) is patched to support it. (With that kind of speedup, I think it's worth it.)
Added as proposal 181.
I'm a little worried about the robustness issue: currently, if an exit node refuses a BEGIN request (because of its exit policy typically) the Tor client will retry at another exit node. But if optimistic data is in use, it seems that the client's initial data will be lost, unless the client keeps a copy around to send to other exits as required.
That's a good point. Perhaps the latter is the right thing to do? That would be sort of a combination of what we do now and the above proposal: buffer the data (as we do now), but also send it (as the proposal). When you eventually receive the CONNECTED, flush anything in the buffer you've already sent. If you eventually receive END instead of CONNECTED, try another circuit, using the buffered data?
As for the application support matter, I wonder how hard it will be to actually get support. We're trying to phase out HTTP proxies in our bundles, so it seems we'd need to tweak browsers to send optimistically.
Don't we already modify the browser in the bundle? You need _something_ (either modifications to the browser or a privacy-aware proxy) to remove any application-level privacy leaks that might exist, right?
- Ian