Re: Design: Adding ASSOCIATED_ONLY

On 21/06/2013 4:53 a.m., James M Snell wrote:
> On Thu, Jun 20, 2013 at 9:20 AM, Amos Jeffries 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

By shared I mean multiple clients may receive the contents. As in shared 
cache vs. private cache.

If the meaning of "shared" for pushed streams still menas the same thing 
it used to they are to be potentialy large streams of non-cacheable data 
containing objects which in a client-fetch stream would be perfectly 
cacheable?
  I can tell you in a nutshell what middleware will do with that type of 
traffic: RST_STREAM.

> 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

But caches are for shared resources. Caches can also be read from while 
the object is still being received from server. Squid collapsed 
forwarding was the feature I had in mind when I wrote the above case 
description.
  Refer (1) "Pushed-Streams are not shared". I smell a definition problem.

> 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.

Go it. Thank you.

Amos

Received on Friday, 21 June 2013 01:20:21 UTC