[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[or-cvs] [tor/master 2/3] Update idea xxx-using-spdy, based on or-dev discussion



Author: Steven Murdoch <Steven.Murdoch@xxxxxxxxxxxx>
Date: Sun, 14 Mar 2010 19:07:52 +0000
Subject: Update idea xxx-using-spdy, based on or-dev discussion
Commit: 9e473bd1bec4671cd909a20d53bde5105f613500

- 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
---
 doc/spec/proposals/ideas/xxx-using-spdy.txt |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/doc/spec/proposals/ideas/xxx-using-spdy.txt b/doc/spec/proposals/ideas/xxx-using-spdy.txt
index 48c51a0..d733a84 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.
-- 
1.6.5