Subject: #446: alt-svc header field syntax

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Apr 2014 10:04:06 +0200

On 2014-03-05 20:59, Julian Reschke wrote:
> So,
>
>>  Alt-Svc     = 1#( alternate *( OWS ";" OWS parameter ) )
>>    alternate   = <"> protocol-id <"> "=" port
>
> <"> can be written better as DQUOTE.
>
> That being said, HTTPbis P2 has this advice:
>
> "Note that double-quote delimiters almost always are used with the
> quoted-string production; using a different syntax inside double-quotes
> will likely cause unnecessary confusion."
>
> So I'd propose to either make it a full blown quoted-string, or to use a
> different quote character ("<" and ">"?).
>
>>    Finally, note that while it may be technically possible to put
>>    content other than printable ASCII in a HTTP header, some
>>    implementations only support ASCII (or a superset of it) in header
>>    field values.  Therefore, this field SHOULD NOT be used to convey
>>    protocol identifiers that are not printable ASCII, or those that
>>    contain quote characters.
>
> The note wrt to quote characters is either a statement of fact (can't),
> or should be a MUST.
>
> A simpler way out of this might be to say:
>
>    alternate   = alt-token "=" port
>    alt-token   = token ; alpn protocol identifier where non-token octets
> are uri-percent-escaped
>
> That (1) avoids quoting, (2) makes it possible to use all syntactically
> valid protocol identifiers, and last but not least (3) makes the common
> case simpler.
>
> Best regards, Julian

So I have made this change in the editor's copy of the spec. The change 
makes the description of the field slightly more complex, but I claim 
actual implementations will simpler.

The field description now reads:

3.  The Alt-Svc HTTP Header Field

    An HTTP(S) origin server can advertise the availability of
    alternative services to clients by adding an Alt-Svc header field to
    responses.

    Alt-Svc     = 1#( alternative *( OWS ";" OWS parameter ) )
    alternative = protocol-id "=" port
    protocol-id = token ; percent-encoded ALPN protocol identifier

    ALPN protocol names are octet sequences with no additional
    constraints on format.  Octets not allowed in tokens ([HTTP-p1],
    Section 3.2.6) MUST be percent-encoded as per Section 2.1 of
    [RFC3986].  Consequently, the octet representing the percent
    character "%" (hex 25) MUST be percent-encoded as well.

    In order to have precisely one way to represent any ALPN protocol
    name, the following additional constraints apply:

    1.  Octets in the ALPN protocol MUST NOT be percent-encoded if they
        are valid token characters except "%", and

    2.  When using percent-encoding, uppercase hex digits MUST be used.

    With these constraints, recipients can apply simple string comparison
    to match protocol identifiers.

    For example:

    Alt-Svc: http2=8000

    This indicates that the "http2" protocol on the same host using the
    indicated port (in this case, 8000).

    Examples for protocol name escaping:

    +--------------------+-------------+---------------------+
    | ALPN protocol name | protocol-id | Note                |
    +--------------------+-------------+---------------------+
    | http2              | http2       | No escaping needed  |
    +--------------------+-------------+---------------------+
    | w=x:y#z            | w%3Dx%3Ay#z | "=" and ":" escaped |
    +--------------------+-------------+---------------------+
    | x%y                | x%25y       | "%" needs escaping  |
    +--------------------+-------------+---------------------+

    Alt-Svc MAY occur in any HTTP response message, regardless of the
    status code.

    Alt-Svc does not allow advertisement of alternative services on other
    hosts, to protect against various header-based attacks.

    It can, however, have multiple values:

    Alt-Svc: h2c=8000, h2=443

    The value(s) advertised by Alt-Svc can be used by clients to open a
    new connection to one or more alternative services immediately, or
    simultaneously with subsequent requests on the same connection.

    Intermediaries MUST NOT change or append Alt-Svc field values.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Apr 2014 10:05:45 -0700

On 1 April 2014 01:04, Julian Reschke <[email-masked]> wrote:
> So I have made this change in the editor's copy of the spec.

LGTM.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Apr 2014 11:05:40 -0700

The examples seem quite clear on where escaping is and is not needed. That
should clear up any need for quoting.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Apr 2014 20:34:12 +0200

On 2014-04-01 20:05, Paul Hoffman wrote:
> The examples seem quite clear on where escaping is and is not needed.
> That should clear up any need for quoting.

Well, the point being that there is no quoting anymore. A protocol name 
in double quotes simply would be invalid according to the ABNF (which 
requires a token).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Apr 2014 11:27:37 +1100

+1, looks good.

On 1 Apr 2014, at 7:04 pm, Julian Reschke <[email-masked]> wrote:

> So I have made this change in the editor's copy of the spec. The change makes the description of the field slightly more complex, but I claim actual implementations will simpler.
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Apr 2014 13:59:42 +1100

Not hearing any pushback, closing the issue.