[tor-dev] Proposal: Optimistic Data for Tor: Client Side

[Nick Mathewson]

On Thu, Jun 2, 2011 at 8:45 PM, Ian Goldberg <iang at 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.

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.

-- 
Nick