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


From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 23 Jul 2013 14:32:31 -0700
Message-ID: <CAP+FsNc5tef8WRCaH-_6z5se=vVPscSQ3+GfEF0T02q8oKq6WA@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: Gábor Molnár <gabor.molnar@sch.bme.hu>, HTTP Working Group <ietf-http-wg@w3.org>
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

> 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

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

This is something we have to test anyway? :)

> -Ilari
Received on Tuesday, 23 July 2013 21:32:58 UTC

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