More SPDY Related Questions..

Jonathan Ballard | 21 Jul 2012 21:57

Re: More SPDY Related Questions..

The way you listed the actions between (A|B)<-->RP<-->O still needs the correct scheme. That is between RP<-->O should show only HTTP 1.1 actions instead of assume the intermediaries will do that for you based on the scheme (SPDY) used between (A|B)<-->RP. In fact, you can write-in "SPDY-O(n)" between (A|B)<-->RP where n is the number of actions/transactions that are not immediately dependent upon O or any action/transactions between RP<-->O. That way, you don't have to list the individual actions accept for the non-schemed actions of HTTP1.1.

Your answers were more obvious when/if SPDY leaks any transience, which is conditional upon concurrency. It appears the complexity of transience was not your intent.

On Saturday, July 21, 2012, James M Snell wrote:

On Sat, Jul 21, 2012 at 12:06 PM, James M Snell <jasnell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
[snip]

2. While we on the subject of Reverse Proxies... the SPDY spec currently states:

When a SYN_STREAM and HEADERS frame which contains an

Associated-To-Stream-ID is received, the client must

not issue GET requests for the resource in the pushed

stream, and instead wait for the pushed stream to arrive.

Question is: Does this restriction apply to intermediaries like Reverse Proxies? For instance, suppose the server is currently pushing a rather large resource to client A and Client B comes along and sends a GET request for that specific resource. Assume that the RP ends up routing both requests to the same backend Origin server. A strict reading of the above requirement means that the RP is required to block Client B's get request until the push to Client A is completed. Further, the spec is not clear if this restriction only applies for requests sent over the same TCP connection. Meaning, a strict reading of this requirement means that even if the RP opens a second connection to the Origin server, it is still forbidden to forward Client B's GET request until Client A's push has been completed.

Side note on this particular item.. if this restriction does apply to intermediaries, then it would be theoretically possible for a malicious or compromised upstream SPDY intermediary to execute a type of DoS on downstream intermediaries by opening push streams and not closing them. Downstream intermediaries would have to be configured to watch for dead push streams.

- James