W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: More SPDY Related Questions..

From: James M Snell <jasnell@gmail.com>
Date: Sat, 21 Jul 2012 12:14:26 -0700
Message-ID: <CABP7RbcojO6xkbBM2JD2NBJn9L8fJntkr0_vnm2v-aeOa6QYLg@mail.gmail.com>
To: ietf-http-wg@w3.org
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
Received on Saturday, 21 July 2012 19:15:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC