Re: #642: Allowing PRIORITY on streams in any any state. [was: Concerns about HTTP/2 Priority]

On Wed, Nov 12, 2014 at 10:33 AM, Mark Nottingham <mnot@mnot.net> wrote:

> This was discussed in the Honolulu meeting; it seemed reasonable to people
> in the room and there was no objection.
>
> Any last thoughts on the list? Otherwise, I’ll mark as editor-ready so
> Martin can integrate the pull request.
>
> ​
I'm fine with this proposal in general.
My comments below.

At first read, I thought that we can only send PRIORITY to idle
stream and idle stream cannot be appeared in priority field
unless it was already in dependency tree.  But it seems I was
wrong.  It seems that PRIORITY or HEADERS can have priority field
to depend on idle stream which is not in a depedency tree yet,
including streams which were depedency tree once but was GC-ed.

For example, when stream A anb B are idle stream and are both not
in dependency tree, sending PRIORITY frame to stream A with
priority field { stream B and weight 20 } creates 2 nodes in
dependency tree.

0 <- B (16)
​ (default priority​ applied)
B <- A (20)

The following paragraph indicates this:

"""
Similarly, streams that are in the "idle" state can be assigned priority or
become a
dependency for other streams.  This allows for the creation of a grouping
node in the
dependency tree, which enables more flexible expressions of priority.  Idle
streams that
are made a dependency are assigned a <xref target="pri-default">default
priority</xref>.
"""

It seems to me that the last sentence "Idle streams that are made
a dependency are assigned a default priority" only applies to
idle stream in dependency field, which is not in dependency tree,
and it is not applied to idle stream that PRIORITY frame is sent
to.  If this sentence also applies to the idle stream which is
already in dependency tree, then everytime it is in priority
field its dependency is reset to default value, which is
undesirable and defeat the purpose of this proposal.  So I think
some texts are required to explicitly state that when this
applies.
​​

Best regards,
Tatsuhiro Tsujikawa​

​​

> Cheers,
>
>
> > On 5 Nov 2014, at 2:28 pm, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > There seems to be some support for this, so I've created <
> https://github.com/http2/http2-spec/issues/642>.
> >
> > As you all know, we need to see substantial support and little (if any)
> dissent to take this kind of change at this point in the process.
> >
> > Anyone else care to comment?
> >
> > The proposal is:
> >
> >> Make it so that PRIORITY can be sent on a stream in ANY state.
> >> i.e., change so that PRIORITY is permitted in the "idle" state.
> >
> >
> > Martin, please start work on a pull so people can take a look.
> >
> >
> >> On 6 Nov 2014, at 2:35 am, Roberto Peon <grmocg@gmail.com> wrote:
> >>
> >> SGTM-- moving this from unreliable to reliable behavior seems like a
> definite win for intermediaries, and potentially others.
> >> -=R
> >>
> >> On Tue, Nov 4, 2014 at 4:40 PM, Ilya Grigorik <igrigorik@gmail.com>
> wrote:
> >> On Wed, Nov 5, 2014 at 8:42 AM, Mark Nottingham <mnot@mnot.net> wrote:
> >> What do other people think about the general idea?
> >>
> >> I like it. I think it moves the discussion from "you could bend the
> protocol to do this assuming you have a cooperating client+server", which
> is not something we can reasonably rely on as a browser, to a plausible
> "PRIORITY is allowed on idle stream, treat such streams as 'group
> anchors'"... i.e. allowing priority on idle stream means servers *must*
> deal with this case, which makes using and deploying such mechanism much
> more plausible.
> >>
> >> ig
> >>
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>