From 315863fa1a7139c46d25229c00cd3c41385f6684 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 17 May 2017 12:40:26 -0400
Subject: [PATCH] more clarification around HTTP/1.x vs HTTP/2
---
draft-dkg-dprive-demux-dns-http.md | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/draft-dkg-dprive-demux-dns-http.md b/draft-dkg-dprive-demux-dns-http.md
index ed07944..32b3df5 100644
--- a/draft-dkg-dprive-demux-dns-http.md
+++ b/draft-dkg-dprive-demux-dns-http.md
@@ -1,5 +1,5 @@
---
-title: Demultiplexing Streamed DNS from HTTP
+title: Demultiplexing Streamed DNS from HTTP/1.x
docname: draft-dkg-dprive-demux-dns-http-02
date: 2017-05-03
category: info
@@ -77,13 +77,13 @@ should place no constraints on it or any higher version of HTTP.
Introduction
============
-DNS and HTTP/1.1 are both client-speaks-first protocols capable of
+DNS and HTTP/1.x are both client-speaks-first protocols capable of
running over stream-based transport like TCP, or as the payload of a
typical TLS {{RFC5246}} session.
There are some contexts where it is useful for a server to be able to
decide what protocol is used by an incoming TCP stream, to choose
-dynamically between DNS and HTTP/1.1 on the basis of the stream itself
+dynamically between DNS and HTTP/1.x on the basis of the stream itself
(rather than a port designation or other explicit demultiplexing).
For example, a TLS terminator listening on port 443 and receiving
@@ -135,7 +135,7 @@ initial few octets sent by the client.
While it's tempting to consider distinguishing at multiple points in
the stream, the complexities of determining the specific end of an
-HTTP/1.1 request body and handling HTTP/1.x error cases make this more
+HTTP/1.x request body and handling HTTP/1.x error cases make this more
difficult to implement on the side of a DNS client configured to talk
to such a server. Interleaving the responses themselves on a stream
with multiple data elements is also challenging. So do not use this
@@ -150,11 +150,13 @@ HTTP/2 is not always client-speaks-first
While this demultiplexing technique functions for HTTP/1.0 and
HTTP/1.1, it does not work for HTTP/2 {{RFC7540}} because HTTP/2 is
-not guaranteed to be a client-speaks-first protocol. In the event
-that HTTP/2 is to be transported over TLS, the ALPN token negotiated
-in the TLS session is "h2", which allows the server to know as soon as
-the handshake is complete that it can start pushing data to the
-client.
+not guaranteed to be a client-speaks-first protocol. In particular,
+many HTTP/2 servers prefer to send a SETTINGS frame immediately
+without waiting for data from the client, if they already know they're
+speaking HTTP/2. In the event that HTTP/2 is to be transported over
+TLS, the ALPN token negotiated in the TLS handshake is "h2", which
+allows the server to know as soon as the handshake is complete that it
+can start pushing data to the client.
A standard DNS-over-TLS client connecting to a server that might be
multiplexing DNS with HTTP on the same listener MUST NOT indicate an
--
GitLab