Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

type the artwork #403

Merged
merged 1 commit into from
Mar 14, 2017
Merged

type the artwork #403

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 11 additions & 5 deletions draft-ietf-quic-http.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,7 +91,9 @@ For example, an origin could indicate in an HTTP/1.1 or HTTP/2 response that
HTTP/QUIC was available on UDP port 443 at the same hostname by including the
following header in any response:

~~~ example
Alt-Svc: hq=":443"
~~~

On receipt of an Alt-Svc header indicating HTTP/QUIC support, a client MAY
attempt to establish a QUIC connection to the indicated host and port and, if
Expand All @@ -107,15 +109,19 @@ This document defines the "quic" parameter for Alt-Svc, which MAY be used to
provide version-negotiation hints to HTTP/QUIC clients. QUIC versions are
four-octet sequences with no additional constraints on format. Syntax:

~~~ abnf
quic = version-number
version-number = 1*8HEXDIG; hex-encoded QUIC version
~~~

Leading zeros SHOULD be omitted for brevity. When multiple versions are
supported, the "quic" parameter MAY be repeated multiple times in a single
Alt-Svc entry. For example, if a server supported both version 0x00000001 and
the version rendered in ASCII as "Q034", it could specify the following header:

~~~ example
Alt-Svc: hq=":443";quic=1;quic=51303334
~~~

Where multiple versions are listed, the order of the values reflects the
server's preference (with the first value being the most preferred version).
Expand Down Expand Up @@ -376,7 +382,7 @@ HTTP/2 framing. For more detail on differences from HTTP/2, see {{h2-frames}}.

All frames have the following format:

~~~~~~~~~~
~~~~~~~~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expand All @@ -402,7 +408,7 @@ One flag is defined:
A HEADERS frame with any other flags set MUST be treated as a connection error
of type HTTP_MALFORMED_HEADERS.

~~~~~~~~~~
~~~~~~~~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expand Down Expand Up @@ -453,7 +459,7 @@ The flags defined are:
: Indicates that the stream dependency is exclusive (see {{!RFC7540}} Section
5.3).

~~~~~~~~~~
~~~~~~~~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expand Down Expand Up @@ -513,7 +519,7 @@ The payload of a SETTINGS frame consists of zero or more parameters, each
consisting of an unsigned 16-bit setting identifier and a length-prefixed binary
value.

~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expand Down Expand Up @@ -602,7 +608,7 @@ the defaults above on the next connection.
The PUSH_PROMISE frame (type=0x05) is used to carry a request header set from
server to client, as in HTTP/2. It defines no flags.

~~~~~~~~~~
~~~~~~~~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expand Down