Subject: PRIORITY stream error?

From: Martin Duke <[email-masked]>
Date: Wed, 6 Mar 2019 12:59:04 -0800

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?

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 6 Mar 2019 21:26:51 +0000

Hey Martin,

> 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

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 6 Mar 2019 13:31:06 -0800

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 <[email-masked]>
wrote:

>> 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

---

From: Ian Swett <[email-masked]>
Date: Wed, 6 Mar 2019 16:34:29 -0500

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=
[email-masked]> 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
>> 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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 7 Mar 2019 07:36:34 +0900

2019年3月7日(木) 5:59 Martin Duke <[email-masked]>:
> Elsewhere, this kind of thing is a connection error.

I am not sure if I agree with the observation. IIUC, the general
approach is to use stream errors when the error does not affect the
entire connection.

It is reasonable for a client to respond with a stream error when it
observes a PRIORITY frame on a *request* stream.

That said, I agree that it should be a connection error when the
client receives a PRIORITY frame on a control frame. That's because we
cannot have a stream-level error for a control stream, because the
stream can never be closed. I think that's what is missing in the
text.

FWIW, we do have this "if the error is X then it's a stream-level
error, or if the error is Y then it's a connection-level error" type
of handling. See section 3.2.2 for an example.

> 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?
>

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Mar 2019 17:43:34 -0500

This view (that the error is localized) is one that we took in HTTP/2.  In retrospect, I don't think that it has been used as much as you would think.  It is far easier to treat violations of spec brutally.  Indeed, this tends to make the problem more visible, which is a good thing.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 6 Mar 2019 23:40:19 +0000

As a general principal (sometimes violated):
If the behavior can be deterministically known to be incorrect, it should probably be a connection error.

In cases where the behavior cannot deterministically be known to be correct (e.g. because of races/timing), it should not be a connection error.

It seems like being "brutal" when possible (as per above) achieves the best interop.
-=R

On 3/6/19, 2:44 PM, "QUIC on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Ian Swett <[email-masked]>
Date: Wed, 6 Mar 2019 18:42:44 -0500

I think Roberto's principles make sense.

In this case, those principles imply the connection should be closed.  I
believe that's true of many of the HTTP/3 errors I'll note.

On Wed, Mar 6, 2019 at 6:40 PM Roberto Peon <[email-masked]> wrote:

> In cases where the behavior cannot deterministically be known to be
> correct (e.g. because of races/timing), it should not be a connection error.
>
> On 3/6/19, 2:44 PM, "QUIC on behalf of Martin Thomson" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     This view (that the error is localized) is one that we took in
> HTTP/2.  In retrospect, I don't think that it has been used as much as you
> would think.  It is far easier to treat violations of spec brutally.
> Indeed, this tends to make the problem more visible, which is a good thing.
>
>     > > 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?
>     > >

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 6 Mar 2019 23:45:48 +0000

I'm not opposed to being brutal.

One thought though. In this case some of the awkwardness comes about
because we have the same stream type - Control - that has different rules
based on directionality. So why not just have two different stream types?
Client control and sender control. This seems more honest with the
asymmetry.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 7 Mar 2019 09:51:41 +0900

> This view (that the error is localized) is one that we took in HTTP/2.  In retrospect, I don't think that it has been used as much as you would think.  It is far easier to treat violations of spec…

I'm fine with changing the approach.

The other issue with using RST_STREAM in response to misbehaving peers
is that the frame does (did) not provide  a way to signal what has
actually been wrong. It has stream_id field, but does not have a
reason_phrase.

I'm supportive to handling all the misbehaviors as connection-level
errors in H3, using RESET_STREAM purely for communicating abrupt
termination of the request.

-- 
Kazuho Oku

---

From: Martin Duke <[email-masked]>
Date: Fri, 8 Mar 2019 13:11:04 -0800

Filed #2507 and PR #2508.

On Wed, Mar 6, 2019 at 4:52 PM Kazuho Oku <[email-masked]> wrote:

> > This view (that the error is localized) is one that we took in HTTP/2.
> In retrospect, I don't think that it has been used as much as you would
> think.  It is far easier to treat violations of spec brutally.  Indeed,
> this tends to make the problem more visible, which is a good thing.
>
> > > 2019年3月7日(木) 5:59 Martin Duke <[email-masked]>:
> > > >