Re: Design: Adding ASSOCIATED_ONLY

Is there a specific use case that needs this?

I suspect there are two camps of browsers:
   - those that disable push
   - those that don't disable push

If you disabled push, then these aren't needed.

If you didn't disable push, do you really need to be able to deal with
batch operations on associated streams?  (I know we can contrive a use-case
on the fly right now - that is always possible.  But if we don't *really*
need it, its just more stuff in the protocol I'd rather omit until we
really know that it is needed.)

Thanks,
Mike



On Wed, Jun 19, 2013 at 11:07 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 19 June 2013 10:56, James M Snell <jasnell@gmail.com> wrote:
> > https://github.com/http2/http2-spec/pull/144
> >
> > This was a technical change brought up and discussed as part of the
> > "layering taskforce" breakout but was never discussed in the larger
> > interim discussions.
> >
> > Essentially, this PR would add an "ASSOCIATED_ONLY" flag to PRIORITY
> > and RST_STREAM frames that would allow terminating and reprioritizing
> > promised streams as a group.
> >
> > Sending PRIORITY(ASSOCIATED_ONLY) would ONLY set the priority for
> > associated streams, not the referenced stream.
> >
> > Sending RST_STREAM(ASSOCIATED_ONLY) would terminate ONLY the
> > associated streams, not the referenced stream.
> >
> > Without this, we would have to send PRIORITY and RST_STREAM for each
> > individual associated stream, which is obviously quite inefficient.
>
> What James omits is:
>
> RST_STREAM is currently specified to terminate all associated streams
> in addition to the parent stream.  This would remove this coupling,
> which is considered by some to be problematic.
>
> It's not possible to reprioritise associated streams as a group.  We
> did agree that associated streams would inherit a priority that is
> lower (by one) than the parent stream.  As it stands, changing all of
> them requires first discovering the stream ID that will be used, then
> sending individual PRIORITY frames for each.
>
> There's not a lot of experience with this area of the specification.
>
>