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@gmail.com<javascript:_e({}, 'cvml', 'jasnell@gmail.com');>
> > 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
>
>