From: Steven Murdoch Date: Sun, 14 Mar 2010 19:07:52 +0000 (+0000) Subject: Update idea xxx-using-spdy, based on or-dev discussion X-Git-Tag: tor-0.2.2.14-alpha~25^2 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9e473bd1bec4671cd909a20d53bde5105f613500;p=thirdparty%2Ftor.git Update idea xxx-using-spdy, based on or-dev discussion - Mention potentially negative consequence of server push, combined with client caching - Make the new cell type more generic, allowing other types of exit-side transforms (suggested by nickm) See http://archives.seul.org/or/dev/Feb-2010/msg00000.html --- diff --git a/doc/spec/proposals/ideas/xxx-using-spdy.txt b/doc/spec/proposals/ideas/xxx-using-spdy.txt index 48c51a0e2d..d733a84b69 100644 --- a/doc/spec/proposals/ideas/xxx-using-spdy.txt +++ b/doc/spec/proposals/ideas/xxx-using-spdy.txt @@ -69,6 +69,12 @@ Target: a HTTP <-> SPDY proxy may improve Tor performance, by some amount. + The consequences on caching need to be considered carefully. + Most of the optimizations SPDY offers have no effect because + the existing HTTP cache control headers are transmitted without + modification. Server push is more problematic, because here + the server may push a resource that the client already has. + 3. Design outline One way to implement the SPDY proxy is for Tor exit nodes to @@ -77,9 +83,10 @@ Target: destined for port 80. Then, rather than sending the usual RELAY_BEGIN cell, the OP - would send a RELAY_SPDY_BEGIN cell, to indicate that the exit - node should translate between SPDY and HTTP. The rest of the - connection process would operate as usual. + would send a RELAY_BEGIN_TRANSFORMED cell, with a parameter to + indicate that the exit node should translate between SPDY and + HTTP. The rest of the connection process would operate as + usual. There would need to be some way of elegantly handling non-HTTP traffic which goes over port 80.