Re: PRIORITY stream error?

[Ian Swett <[e-mail]>]

Recently in transport(Issue #2487
<https://github.com/quicwg/base-drafts/issues/2487>), members of the
working group have favored fatal connection close errors over accepting
questionable values, so I agree that this should be a connection close
error.

On Wed, Mar 6, 2019 at 4:31 PM Ryan Hamilton <rch=
[e-mail]> wrote:

> I agree with Martin on this; it smells like a connection error. Making
> this a stream error in order to collect more details doesn't seem terribly
> useful, and in any case, the endpoint could stuff more info (like the
> stream id) into the reason phrase field.
>
> On Wed, Mar 6, 2019 at 1:27 PM Lucas Pardue <[e-mail]>
> wrote:
>
>> Hey Martin,
>>
>> On Wed, 6 Mar 2019, 20:59 Martin Duke, <[e-mail]> wrote:
>>
>>> the very end of Section 4.2.3 of quic-http says:
>>>
>>>    PRIORITY frames received by a client MUST be treated as a stream
>>>    error of type HTTP_UNEXPECTED_FRAME.
>>>
>>>
>>> Elsewhere, this kind of thing is a connection error. Making this a
>>> stream error seems problematic; if otherwise valid, if this goes out on the
>>> control stream a stream error may bring everything down anyway?
>>>
>>> Should this be a connection error, or am I missing something?
>>>
>>
>> My thinking is that if you send this in a RESET_STREAM  the other
>> endpoint knows what stream the offending was sent on. Just getting this in
>> CONNECTION close is quite a broad error.
>>
>> Also note that endpoints are free to treat stream errors as connection
>> errors Iif they want, so you can go straight to that route if you want.
>>
>> Cheers
>> Lucas
>>
>>>