Re: PRIORITY stream error?

["Martin Thomson" <[e-mail]>]

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.

On Thu, Mar 7, 2019, at 09:37, Kazuho Oku wrote:
> 2019年3月7日(木) 5:59 Martin Duke <[e-mail]>:
> >
> > 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.
> 
> 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?
> >
> > Should this be a connection error, or am I missing something?
> 
> 
> 
> -- 
> Kazuho Oku
> 
>