Re: New Version Notification for draft-ietf-httpbis-priority-00.txt

2020年3月6日(金) 11:12 Ian Swett <ianswett@google.com>:

> I think it would be nice to allow the frame on the request stream, but
> it's not a must.  The current design works from my perspective, but it uses
> a few more bytes.  If others support allowing it on the request stream, I'd
> be supportive, and the additional code is tiny, but I'm not going to fight
> for it really strongly and I certainly don't want to delay this effort to
> fight for it.
>
>
I think my preference goes to sending priority only on the control stream,
for simplicity and robustness.

Having two ways to signal priorities through a frame is complex.

I would point out that Chrome (as it is now) sends the PRIORITY_UPDATE
frame on the control stream before the HEADERS frame on the request stream,
and I like it.

QUIC does not have ordering guarantee between streams, and that means that
there's always chance for a PRIORITY_UPDATE frame to arrive after the
prioritization signal sent on the request stream, regardless of that signal
being a header field or a frame.

Therefore, servers ought to buffer the information conveyed in the
PRIORITY_UPDATE frame being received on the control stream. The current
behavior of Chrome helps server developers do that.


> I hope that's slightly clearer.
>
> Thanks, Ian
>
> On Thu, Mar 5, 2020 at 4:54 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>> I agree with the points made but I think my question was unclear of my
>> intent. So let me rephrase it as: HTTP/2 allows the PRIORITY frame to be
>> sent on a stream at any point. Do we want to allow NU_PRIORITY on request
>> streams but constrain the states that it can be sent in?
>>
>> Given that we're trying to define something that works equivalently
>> across HTTP/2 and HTTP/3, my inclination is that restricting NU_PRIORITY to
>> stream 0 and the control stream achieves that.
>>
>>
>> On Thu, Mar 5, 2020 at 9:40 PM Ian Swett <ianswett@google.com> wrote:
>>
>>> Martin's concern is exactly right.
>>>
>>> On Thu, Mar 5, 2020 at 4:24 PM Martin Thomson <mt@lowentropy.net> wrote:
>>>
>>>> On Fri, Mar 6, 2020, at 07:43, Roberto Peon wrote:
>>>> > Until HTTP offers chunk-extensions again, I don’t see how it can be
>>>> otherwise?
>>>>
>>>> I don't think that's the concern, it's that there is no way for a
>>>> client to send an update if the request stream is closed.  At least in QUIC.
>>>>
>>>>

-- 
Kazuho Oku