Hi Patrick--
On Wed 2017-05-03 14:57:24 -0400, Patrick McManus wrote:
> My initial response is that legacy HTTP/1 implementations will sink you by
> scanning for stuff that looks like HTTP in your stream - even if the
> leading bytes don't match the production those RFCs required (and HTTP/1.0
> is only informational anyhow). You can look at the websockets masking
> madness to see the lengths the community went to to avoid that kind of
> detection in rfc 6455.
Are you talking about an existing HTTP/1 server implementation? The
idea of the demuxing stage is that a server that opts into this would
put the demuxing *before* the HTTP/1 server implementation gets access
to the data.
> Coincidentally I have a draft with Paul Hoffman that we're close to
> publishing, that describes how to do DNS over https:// in a way that I
> think will play better with both the http and dns ecosystems than previous
> work in that area. It wouldn't be a http-wg item though, we don't normally
> take FOO-over-HTTP drafts here. That might be a better option - if you want
> to use the https port, and the https alpn token, perhaps the https protocol
> (without constraining its future) is the right choice :)
is the draft you and Paul are working on different than
ietf-dnsop-dns-wireformat-http ? Can they be reconciled? See my
response to Roy T. Fielding (upthread) for why the demux approach seems
cleaner and safer for clients as long as we're using stream-based
transport.
I certainly wouldn't want this work to get in the way of
ietf-dnsop-dns-wireformat-http (or any similar proposal), but i don't
think it does. does it?
--dkg
Received on Wednesday, 3 May 2017 23:22:33 UTC