[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