I've been thinking about some of the SPDY issues that have come up and have a couple of ideas.
First, the SPDY SM is really a client session. It handles input from a client socket and drives the transactions through the system, without interacting (directly) with any of the origin servers or the cache. If we take that viewpoint then we can add the concept of parent/child relationships between client sessions which in turn lets us associate a specific SPDY session with an HTTP transaction in a reasonably generic way. We would require the parent client session to keep track of which subsidiary client sessions are active but this should already be the case. We have the ClientSession cleanup clear the parent pointer and depend on the parent CS to do its own bookkeeping. With regard to session protocols and configuration, I think I want to set up something like the HdrToken thing for protocol names, "registered protocol session names". We pre-populate it with our well known names and add any names that come in from a plugin. We can then use these indices straight up or as bit indices for tracking sets of session protocols. Beyond that we could use these for TSProtoStack rather than hard wired values. At the intersection of these two things is the utility of being able, from a transaction (HttpSM) to be able to detect the wrapping session protocol (if any). We could either store the registered protocol session name index (because there can be only one at the session level) or we could reach up through the client session to its parent to provide that data.
