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

Re: More SPDY Related Questions..

From: Jonathan Ballard <dzonatas@gmail.com>
Date: Sat, 21 Jul 2012 12:57:39 -0700
Message-ID: <CAAPAK-4xtWg8mvR5PphfGtiq-fWevypuvvJZv1iqG7doA7k0Sg@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
Received on Saturday, 21 July 2012 19:58:06 UTC

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