Re: [quicwg/base-drafts] http: Allow unquoted tokens in Alt-Svc quic parameter (#3063)

Peter Wu <notifications@github.com> Sun, 29 September 2019 15:47 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE171200DE for <quic-issues@ietfa.amsl.com>; Sun, 29 Sep 2019 08:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jTSNfs83OvwK for <quic-issues@ietfa.amsl.com>; Sun, 29 Sep 2019 08:47:33 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E75C1200D8 for <quic-issues@ietf.org>; Sun, 29 Sep 2019 08:47:33 -0700 (PDT)
Received: from github-lowworker-2e54e43.va3-iad.github.net (github-lowworker-2e54e43.va3-iad.github.net [10.48.17.27]) by smtp.github.com (Postfix) with ESMTP id 3A564A0441 for <quic-issues@ietf.org>; Sun, 29 Sep 2019 08:47:32 -0700 (PDT)
Date: Sun, 29 Sep 2019 08:47:32 -0700
From: Peter Wu <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK36XY45P6X3YDMHSK53TYJKJEVBNHHB3JNFTE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3063/536314485@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3063@github.com>
References: <quicwg/base-drafts/issues/3063@github.com>
Subject: Re: [quicwg/base-drafts] http: Allow unquoted tokens in Alt-Svc quic parameter (#3063)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d90d2142ab25_238f3fc0948cd96481989f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: Lekensteyn
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/SZ7v6ztHxt0ZiSzRIk7XkHfO5wQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Sep 2019 15:47:35 -0000

I think that the problem here is independent from whether structured headers should be applied or not.

- `Alt-Svc: h3=":443"; quic=1; quic=1abadaba` - Structured header issue: duplicate keys.
- `Alt-Svc: h3=":443"; quic=1,1abadaba` - Invalid grammar according to RFC 7838 since "token" does not include commas.
- `Alt-Svc: h3=":443"; quic="1,1abadaba"` - valid grammar according to both RFC 7838 and the QUIC description.

However, if only a single version has to be advertised, then the quoting is not necessary:
- `Alt-Svc: h3=":443"; quic="1"` - valid grammar according to both RFC 7838 and the QUIC description.
- `Alt-Svc: h3=":443"; quic=1` - valid grammar according to both RFC 7838, but QUIC currently forbids it.

In #3059 I proposed to fix the grammar (editorial issue). However, at the same time I could also make the grammar match RFC 7838 (the last bullet point above).

@DavidSchinazi I would mind not making the semantics more restrictive (e.g. restricting the values of the QUIC parameter to hexadecimal only), but restricting the parser grammar would impose extra restrictions on those who have to generate the header. It is conceivable that implementations will continue accepting the RFC 7838 grammar, and end up accepting `quic=1` while others would reject it and accept `quic="1"` only. By making sure that the grammars align, I hope that this becomes a non-issue.

So far @mikkelfj, @tatsuhiro-t and @bagder seems to support this proposal and @DavidSchinazi is not sure. Can this be considered consensus? :smiley:

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3063#issuecomment-536314485