Re: More SPDY Related Questions..

There are max concurrency limits which are set by the each side. This
limits the effectiveness of an attack by the intermediary, or any spec
compliant implementation , proxy or not.

While you are correct that this would DoS the client, the intermediary
could do easier and cheaper DoS such as dropping the requests.

All intermediaries must watch the total number of sessions all the time
anyway...

-=R
On Jul 21, 2012 12:16 PM, "James M Snell" <jasnell@gmail.com> wrote:

>
> On Sat, Jul 21, 2012 at 12:06 PM, James M Snell <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
>
>