Re: Push ID - Merge Imminent

I think the high-order idea is great, and I'm totally in favor. I've raised
several editorial issues, but there's one substantitive one that may be
worth discussing here.

PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the
server. The text currently says that CANCEL_PUSH on a non-existent Push ID
results in error, which does not work with the possibility of reordering
between PUSH_PROMISE and CANCEL_PUSH. Similarly, it's also possible for the
PUSH_PROMISE to not have been received because the stream on which it was
sent was reset... basically it's possible for a client to receive a
CANCEL_PUSH without seeing the corresponding PUSH_PROMISE.

We could have CANCEL_PUSH be sent on the same streams as the PUSH_PROMISE,
but that doesn't help with the case where the PUSH_PROMISE may not have
been received due to a stream reset.

This makes me wonder if it makes sense to always send the PUSH_PROMISE on
the control stream *in addition to* any stream that it is sent on. This
would ensure that no matter what, the PUSH_PROMISE is always received, and
additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE.

- jana

On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop <>

> Bah, QUIC too.  😊
> *From:* Mike Bishop []
> *Sent:* Thursday, August 3, 2017 10:36 AM
> *To:*
> *Subject:* Push ID - Merge Imminent
> This is Martin’s Push ID PR split off from unidirectional.  Given that it
> has already been picked over in those contexts and the feedback from that
> and in-person discussion was to bring this change in separately, I’m about
> ready to merge this.  Everything anyone has quibbled with has been
> editorial.  However, I don’t see reviews from many folks, so I want to make
> sure that everyone interested has had a chance to express an opinion.
> <>
> I’ll give it a few hours (until everyone’s had at least a little bit of a
> work day), then merge unless I hear otherwise.

Received on Friday, 4 August 2017 00:32:22 UTC