Skip to content

Commit

Permalink
Alt-Svc text -- starts to address #87
Browse files Browse the repository at this point in the history
  • Loading branch information
MikeBishop committed Dec 16, 2016
1 parent a1dba3f commit f324fd9
Showing 1 changed file with 84 additions and 11 deletions.
95 changes: 84 additions & 11 deletions draft-ietf-quic-http.md
Expand Up @@ -97,27 +97,71 @@ defined in {{!RFC2119}}.

# QUIC advertisement

A server advertises that it can speak HTTP-over-QUIC via the Alt-Svc HTTP
response header. It does so by including the header in any response sent over a
non-QUIC (e.g. HTTP/2) connection:
A server advertises that it can speak HTTP/QUIC via the Alt-Svc
({{!RFC7838}}) HTTP response header, using the ALPN token "hq".

Alt-Svc: quic=":443"
Thus, a server could indicate in an HTTP/1.1 or HTTP/2 response that HTTP/QUIC
was available on UDP port 443 by including the following header in any
response:

In addition, the list of QUIC versions supported by the server can be specified
by the v= parameter. For example, if a server supported both version 33 and 34
it would specify the following header:
Alt-Svc: hq=":443"

Alt-Svc: quic=":443"; v="34,33"
## Draft version identification

> **RFC Editor's Note:** Please remove this section prior to publication of a
> final version of this document.

On receipt of this header, a client may attempt to establish a QUIC connection
Only implementations of the final, published RFC can identify themselves as
"hq". Until such an RFC exists, implementations MUST NOT identify themselves
using these strings.

Implementations of draft versions of the protocol MUST add the string "-" and
the corresponding draft number to the identifier. For example,
draft-ietf-quic-http-01 is identified using the string "hq-01".

Non-compatible experiments that are based on these draft versions MUST append
the string "-" and an experiment name to the identifier. For example, an
experimental implementation based on draft-ietf-quic-http-09 which reserves an
extra stream for unsolicited transmission of 1980s pop music might identify
itself as "hq-09-rickroll". Note that any label MUST conform to the "token"
syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are encouraged to
coordinate their experiments on the ietf-quic-wg@w3.org mailing list.

## QUIC version hints {#alt-svc-version-hint}

This document defines the "v" parameter for Alt-Svc, which is used to provide
version-negotiation hints to HTTP/QUIC clients.

In addition, a list of QUIC versions supported by the server can be specified by
the v= parameter. Syntax:

v = quoted-versions
quoted-versions = DQUOTE *( version-string "," ) version-string DQUOTE
version-string = token; percent-encoded QUIC version

For example, if a server supported both version Q033 and Q034 it would specify
the following header:

Alt-Svc: hq=":443"; v="Q034,Q033"

Where multiple versions are listed, the order of the values reflects the
server's preference (with the first value being the most preferred version).

QUIC versions are four-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.

On receipt of this header, a client MAY attempt to establish a QUIC connection
on port 443 and, if successful, send HTTP requests using the mapping described
in this document.
in this document. Servers SHOULD list only versions which they support, but MAY
omit supported versions for any reason.

Connectivity problems (e.g. firewall blocking UDP) may result in QUIC connection
establishment failure, in which case the client should gracefully fall back to
HTTP/2.


# Connection establishment

HTTP-over-QUIC connections are established as described in {{QUIC-TRANSPORT}}.
Expand Down Expand Up @@ -747,6 +791,35 @@ HTTP/2.

# IANA Considerations

## Registration of HTTP/QUIC Identification String

This document creates a new registration for the identification of HTTP/QUIC in
the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry
established in {{?RFC7301}}.

This comment has been minimized.

Copy link
@LPardue

LPardue Dec 19, 2016

Member

{{?RFC7301}} is a typo for {{!RFC7301}}?

This comment has been minimized.

Copy link
@MikeBishop

MikeBishop Dec 20, 2016

Author Contributor

No, intentional, though I'm borderline. QUIC doesn't actually require the use of ALPN. QUIC requires that the crypto handshake, whatever it might be, provide application-level protocol negotiation capabilities. When using TLS 1.3 as the crypto protocol, ALPN is used to satisfy this requirement.

So while HTTP/QUIC specifies a token to be used, and registers it in case you're using it with ALPN, a different crypto handshake could use a different negotiation protocol with a different registry and still work with HTTP/QUIC. ALPN itself isn't a hard requirement to implement HTTP/QUIC, which to me says non-normative.

But practically, we have no other crypto protocol currently defined and we're strongly assuming the use ALPN, so it's... nearly normative.


The "hq" string identifies HTTP/QUIC:

Protocol:
: HTTP over QUIC

Identification Sequence:
: 0x68 0x71 ("hq")

Specification:
: This document

## Registration of Version Hint Alt-Svc Parameter

This document creates a new registration for version-negotiation hints in the
"Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" registry established in
{{!RFC7838}}.

Parameter:
: "v"

Specification:
: This document, {{alt-svc-version-hint}}

## Existing Frame Types

This document adds two new columns to the "HTTP/2 Frame Type" registry defined in
Expand Down

0 comments on commit f324fd9

Please sign in to comment.