On May 16, 2014, at 2:29 PM, Alan M. Carroll <a...@network-geographics.com>
wrote:
> 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.
Hmmm, is that always going to be the case? I’d imagine that we (long term)
support the following types of sessions:
Client Proxy Origin
——— ——— -------
HTTP HTTP HTTP
HTTP HTTP HTTPS
HTTPS HTTPS HTTP
HTTPS HTTPS HTTPS
SPDY SPDY/HTTP HTTP
SPDY SPDY/HTTP HTTPS
SPDY SPDY/SPDY SPDY
HTTP HTTP/SPDY SPDY
HTTPS HTTP/SPDY SPDY
In some of these cases, I’d imagine we could / should bypass the HttpSM, and
have SPDY read / write to the cache directly, or talk to origins directly. In a
sense, if things pan out for HTTP/2 as they like, we’d no longer have to
support the HttpSM (yeah, that will never happen, but still …).
— leif
