W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Design: Adding ASSOCIATED_ONLY

From: James M Snell <jasnell@gmail.com>
Date: Thu, 20 Jun 2013 09:53:03 -0700
Message-ID: <CABP7RbcYMPK81+ofJeP4T5OxS2+CWH0iafwktTwkr8ek_Lv5bA@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Thu, Jun 20, 2013 at 9:20 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>[snip]
>
> Possibly. I can also think of a very likely scenario which this will cause
> problems for.
>
> 1) Middleware which is caching the pushed resources will not be happy to
> have them terminated incompletely received even if the user has closed the
> main non-cacheable stream.
>
> 2) Middleware serving the pushed objects up to multiple clients in parallel
> will be quite put out to have the streams discontinued underneath it simply
> because they were associated as secondary resources with _one_ particular
> client who went away.
> [snip]

Not following the thought here. There are several important things to remember:

1. Pushed-Streams are not shared, and
2. Pushed-Streams are always hop-by-hop

This was a point that was raised at the interim and discussed at length.

For example, suppose a client A sends a request through caching proxy
B to origin server C.

C receives the request and sends PUSH_PROMISE frames to B as part of
its response. B can accept those pushed streams from C but it is not
required to send PUSH_PROMISE frames to A. It can choose, for
instance, to just use the pushed streams to populate it's local cache
and have A send GET requests for each of those cached resources. There
might be a delay in B responding to those GET's while it receives the
data from C, but that's not important here. If B does decide to send
PUSH_PROMISE frames to A, those pushed streams are completely
independent of the streams C is pushing to B, even if they are for the
same resources. A can send a RST_STREAM to B terminating a pushed
stream, but that has absolutely no effect on the stream being pushed
from C to B, even if it is for the same resource. And A sending a
RST_STREAM for a pushed stream has absolutely no effect on any other
stream B might be pushing to any other client. So, sending a
RST_STREAM(ASSOCIATED_ONLY) has ZERO impact on what middleware might
do with multiple clients. It only terminates the pushed streams being
exchanged between two points.

- James
Received on Thursday, 20 June 2013 16:53:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC