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

From: Peter Wu <[email-masked]>
Date: Mon, 23 Sep 2019 17:45:29 -0700

According to https://tools.ietf.org/html/rfc7838#section-3, the Alt-Svc parameter value can be unquoted:
```
    parameter = token "=" ( token / quoted-string )
```

This means that this can be written:
```
alt-svc: h3=":443";quic=1
```
instead of only:
```
alt-svc: h3=":443";quic="1"
```

The current text in https://tools.ietf.org/html/draft-ietf-quic-http-23#section-3.2.1 forbids the unquoted variant which is an additional constraint on the RFC 7838 grammar. Should unquoted `quic` parameter values also be permitted?

Note that this does not change the situation when multiple versions are supported since an unquoted "token" type is not allowed to contain commas.

See also the discussion in #3059.

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 23 Sep 2019 18:23:11 -0700

RFC 7838 allows unquoted strings, but there's nothing preventing new specifications of Alt-Svc parameters from being more restrictive. I'm not sure the added flexibility of allowing unquoted versions buys us much here, and it comes at an implementation cost.

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 23 Sep 2019 23:54:33 -0700

If alt-svc can be specified in configuration files, it is likely to result in interop issues if unquoted is not permitted.

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

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Tue, 24 Sep 2019 07:30:23 -0700

I support allowing unquoted token for alt-svc quic parameter.
quic=1 and quic="1" are semantically the same, and there is no reason to disallow unquoted token.
Moreover, requiring quoted-string means that we cannot use generic alt-svc parser because such parser can parse quic=1 without an error.  You need to write your own parser to detect that the DQUOTE is really there.  If you think that detecting it is not necessary, then requiring quoted-string is not necessary in the first place.

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

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 24 Sep 2019 07:32:03 -0700

People and implementers will be surprised (and do wrong) if the rules and constraints of RFC7838 aren't kept.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 25 Sep 2019 05:24:12 -0700

To highlight my earlier point, on slack the following was posted 

> Specifically: I have an H1/H2 server running on ports 443 and 4433 which advertises
> alt-svc: h3-23=":4433"; ma=3600

The issue appears to not be the unquoted ma=3600, but it does suggest we will see unquoted strings in the wild.

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

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 25 Sep 2019 06:06:28 -0700

But that's the ma= field, not the quic= field, right? (This issue is about
the quic= field, I think)

On Wed, Sep 25, 2019 at 5:24 AM MikkelFJ <[email-masked]> wrote:

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3063?email_source=notifications&email_token=AEVHVSVMASRXRELYTEAKLWTQLNJ6XA5CNFSM4IZWYYM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7RWLWQ#issuecomment-534996442>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AEVHVSSU5ZHOPBWYSKQ4GJTQLNJ6XANCNFSM4IZWYYMQ>
> .
>

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

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 25 Sep 2019 06:24:28 -0700

As I said elsewhere, the current text in draft-23 stems from a Structured Headers issue related to wanting to advertise multiple versions of QUIC.  https://github.com/httpwg/http-extensions/issues/281

Alt-Svc isn't a structured one but if it were (e.g. if someone wanted to write a generic Structured Header parser) then there was a danger that the rules preventing dictionary key repetition would have prevented an endpoint sending multiple `quic` parameters e.g. `Alt-svc: ":443"; quic=1; quic=1abadaba`.

To mitigate the risk, the quic parameter was changed to a DQUOTED comma-separated list as part of https://github.com/quicwg/base-drafts/issues/1093.

This issue addresses the correctness within the Alt-Svc spec but does it reopen the can related to Structured Headers?

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

---

From: Peter Wu <[email-masked]>
Date: Sun, 29 Sep 2019 08:47:32 -0700

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