Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

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.

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

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

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

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

-Ilari

Received on Tuesday, 23 July 2013 19:04:45 UTC