http: Allow unquoted tokens in Alt-Svc quic parameter

[Lekensteyn]

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.

[DavidSchinazi]

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.

[mikkelfj]

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

[tatsuhiro-t]

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.

[bagder]

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

[mikkelfj]

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, and quic.rocks is said to also use unquoted ma=3600.

[RyanTheOptimist]

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 ***@***.***> wrote: 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, view it on GitHub <#3063?email_source=notifications&email_token=AEVHVSVMASRXRELYTEAKLWTQLNJ6XA5CNFSM4IZWYYM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7RWLWQ#issuecomment-534996442>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEVHVSSU5ZHOPBWYSKQ4GJTQLNJ6XANCNFSM4IZWYYMQ> .

[LPardue]

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. httpwg/http-extensions#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 #1093.

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

[Lekensteyn]

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