#492: Alt-Svc header host restriction

Hi there,

turns out that this is a bit messy:

1) People usually think of "host:port", and using that syntax requires 
putting the value into double quotes, as ":" is a token character -- 
unless we choose a different delimiter.

2) I started with the allowing either a simple port (as used before), or 
host:port, but here the problem is that a naked port number can be 
parsed as host name as well. Thus the colon becomes required even is the 
host part is absent.

With that, I currently have:


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 "=" alt-authority
    protocol-id   = token ; percent-encoded ALPN protocol identifier
    alt-authority = token / quoted-string
                    ; containing [ uri-host ] ":" port

    ALPN protocol names are octet sequences with no additional
    constraints on format.  Octets not allowed in tokens ([RFC7230],
    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.

    The "alt-authority" component consists of an OPTIONAL uri-host
    ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port
    number.

    For example:

    Alt-Svc: http2=":8000"

    This indicates the "http2" protocol on the same host using the
    indicated port 8000.

    An example involving a change of host:

    Alt-Svc: http2="new.example.org:80"

    This indicates the "http2" protocol on the host "new.example.org",
    running on port 80.  Note that the "quoted-string" syntax needs to be
    used when a host is specified in addition to a port (":" is not an
    allowed character in "token").

    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.

    To reduce the ability of servers to track individual clients over
    time (see Section 9.4), an alternative service indication sent by a
    client SHOULD NOT include any alternative service information other
    than the protocol, host and port.

    When using HTTP/2 ([HTTP2]), clients SHOULD instead send an ALTSVC
    frame.  A single ALTSVC frame can be sent for a connection; a new
    frame is not needed for every request.

    Note that all field elements that allow "quoted-string" syntax MUST
    be processed as per Section 3.2.6 of [RFC7230].

Can people live with that or should we try to come up with something 
more elegant?

Best regards, Julian

PS: maybe it's time to start using JSON in header field values.

Received on Thursday, 12 June 2014 13:34:29 UTC