Re: PRIORITY stream error?

Kazuho Oku <kazuhooku@gmail.com> Thu, 07 March 2019 00:51 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A52131142 for <quic@ietfa.amsl.com>; Wed, 6 Mar 2019 16:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRxIHzI-wICZ for <quic@ietfa.amsl.com>; Wed, 6 Mar 2019 16:51:54 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B03313113E for <quic@ietf.org>; Wed, 6 Mar 2019 16:51:54 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id r123so10342932lff.6 for <quic@ietf.org>; Wed, 06 Mar 2019 16:51:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0gf/DCG83u/3llJGr6fEGqvNILmldb8oltodiJeZHLA=; b=DYU+pyDwIMwpO3cIgLQvuoj9wctbfmODz1wNktD/HNgp1LHUVYOwkdbv57b2RfpDGP 3vkhe0gz9Mxt868NNbSqmlkVRwFq8+tGOTw25URQBfaeHnKh/kK50q4uP9WcuDJqqrEX bnfX8tc17Tbp+PTfBJMxlCrf/kqxzj5R5KgdmO5pqYgndpiCMkXLW7o4+PhqBRaQTRuh RLfBRidbgiISfBIHe8PZ4392fz2tZn4jYjGNJMSwJAyMppXU6RquTgloI/GLTKj9rHre 9hzc73Ofr09qNtrpt3o00Kcb3ir6WvBOXPx2sTIioR+lnxATu+wh3tH8TuLeYOO4MwNz OL4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0gf/DCG83u/3llJGr6fEGqvNILmldb8oltodiJeZHLA=; b=MaHZwuM7LiQ1x468RmvdzbwKI2E0Lf2vQ5CvtQf7GM8njyQ0vCSadzmlffKQ6lluYh MM7f3PK7VelKUzlppF/u/5JsQ3SL20J3PqeWN04vjLP5lNlSzGMBoHKpVQv0szWmsz4G yWnJtY1RzXh08b+CMRG4+Qcedxyry2iCyIybLD86bAy8/ZRevAUoCOBVWulTm/Xncnmh LJ/RorxTAdrDUlB3PbAX2YEIEaZkCWSioWCrep8RlFEdNLY1csWwNNDTAC0jWdKFFbUs ocKLaGDXoAsDo3RZSCzbWfIZgAqZRGF1DZ6CLI8GJyNxTzLfKuQKmvwZ7C03pr1CWyEW 1DPg==
X-Gm-Message-State: APjAAAVfhe1kBU6LcknDiMvsj6ErdraW4xM0fY+ExraFqyCJJe0dglF8 52LNdvlloHz8HxiaNJO+5oeB3FGPLl1dG/0ZIShR8g==
X-Google-Smtp-Source: APXvYqyCxLSye4yATWvBAnrptp+Dl5WMnWGeYh0csvKQu/mrmO6K89cRT2gxJT677VcS9rjfA6CLtqhz6wAabvNuDkY=
X-Received: by 2002:ac2:5228:: with SMTP id i8mr5392651lfl.162.1551919912253; Wed, 06 Mar 2019 16:51:52 -0800 (PST)
MIME-Version: 1.0
References: <CAM4esxRy-F5xjdQxc1sNt4atr840DtD9Z=L8nBUE-jvDZ9154w@mail.gmail.com> <CANatvzxghmoCbrVEYw6BkLt99-i8p+AfNnaqnbeR6m8TkuZBeA@mail.gmail.com> <207a34cc-8b35-4944-9eb3-1661930686ce@www.fastmail.com>
In-Reply-To: <207a34cc-8b35-4944-9eb3-1661930686ce@www.fastmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 07 Mar 2019 09:51:41 +0900
Message-ID: <CANatvzwd3rOC2A+B5DZkhGwwK0ZsCdBS4hQwRTKwpOd4TK3x=g@mail.gmail.com>
Subject: Re: PRIORITY stream error?
To: Martin Thomson <mt@lowentropy.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rJTGHKjUvNRngmAP2wY7uidNIss>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 00:51:56 -0000

2019年3月7日(木) 7:43 Martin Thomson <mt@lowentropy.net>:
>
> 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.

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.

>
> On Thu, Mar 7, 2019, at 09:37, Kazuho Oku wrote:
> > 2019年3月7日(木) 5:59 Martin Duke <martin.h.duke@gmail.com>:
> > >
> > > 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
> >
> >
>


-- 
Kazuho Oku