Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

responses inline


On Tue, Jul 23, 2013 at 12:04 PM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Tue, Jul 23, 2013 at 10:01:31AM -0700, Roberto Peon wrote:
> > The whole point of push-promise is to not count them, and so to avoid the
> > condition where the number of resources it wishes to push exceed the max
> > concurrent stream limit, causingna race.
>
> How it does cause a race? Stall the associated stream and open some
> promised
> streams if you have slots for it (if not, complete some old open pushed
> streams first). No races there.
>

The client, having no indication that a particular resource will be pushed,
will instead request the resource, and now the server may be pushing a
resource for which it is also responding to the client, solely because the
advertisement about what it was going to push was delayed.
In other words, that is a race if the server ever does intend to push the
resource.


>
> Or are you talking about client shrinking number of allowed promised frames
> mid-connection? Yeah, that sort of thing is fundamentally racy.
>

That would also be racy. Any limit would be racy.
The number of resources in a web page are not limited, thus the number of
signals that the resources will be pushed needs to be symmetrically
unlimited.


>
> > E.g. if max concurrent stream limit is 10, but I have 21 resources to
> push.
> > If push-promise counted, I'd be unable to advertise push promise for all
> of
> > these resources, potentially causing a race on the 11 resources the
> server
> > was not allowed to send luah-promise for. This would be true even if I
> was
> > sending the resources one at a time...
>
> Any sensible client (and especially proxy) is going to
> RST_STREAM(REFUSED_STREAM) any promised stream over some limit.
>
> Otherwise, have fun with 1,000,000,000 promised streams... And promised
> streams are not free for client/proxy.
>

True, you can get into abusive edge-cases where it is preferable to forget
about the push promise and allow the race.
In such cases, the client would RST the promised stream and request it.
This is a race with very different resultant semantics-- the server won't
be using up the available bandwidth twice at once. The client will know
exactly what it is doing.


>
> > You ask a separate question about whether or not push-promise can be sent
> > when max-concurrency is 0. Personally, I don't see any real harm in it.
> The
> > client can discard the data after putting them through the compressor.
> > Push-promise is only distinguishable from the headers  frame by the
> opcode,
> > so we should be talking about very minimal amounts of code.
>
> I regard that operation as just plain nonsense.
>

Then you're not thinking deeply enough yet :)
Even if push promises were limited by some configuration, changes to that
configuration can cause this condition to occur. Thus, clients must be able
to handle PUSH_PROMISE frames by at least discarding them.


>
> Want to test if client is going to send back RST_STREAM(REFUSED_STREAM) or
> GOAWAY(INTERNAL_ERROR)? :-)
>

This is something we have to test anyway? :)
-=R


>
> -Ilari
>