- From: Eggert, Lars <lars@netapp.com>
- Date: Mon, 15 Apr 2013 22:27:17 +0000
- To: Roberto Peon <grmocg@gmail.com>
- CC: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, Eliot Lear <lear@cisco.com>, Robert Collins <robertc@squid-cache.org>, Jitu Padhye <padhye@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com>, Rob Trace <Rob.Trace@microsoft.com>, "Dave Thaler" <dthaler@microsoft.com>, Martin Thomson <martin.thomson@skype.net>, Martin Stiemerling <martin.stiemerling@neclab.eu>
Hi, On Apr 15, 2013, at 15:15, Roberto Peon <grmocg@gmail.com> wrote: > If it was defined as an opaque blob that the transport layer delegates to > the application layer to transmit and cache, would it seem as scary? ... > I think you mistake the intent. The intent is to make it easy for transport > experimentation by giving a mechanism that can be implemented today of > storing transport-related data, and by giving that back to the transport > layer upon session resumption. why does the app need to be involved here at all? It TCP wants to cache state from one connection instance to the next, it can (and does, in some cases) already do so. Yeah, for HTTP, you might want the HTTP client to hold that state instead of the HTTP server as an optimization, so you need to get it in and out of the server kernel. But is that really of general usefulness? There seem to be some significant security challenges here, such as whether a server would even trust this opaque information, given that the client could have messed with it. (Blindly using this state could have detrimental effects on other connections the server has open.) Lars
Received on Monday, 22 April 2013 08:06:49 UTC