Subject: [Doh] Hackathon javascript client & browser issue

From: Tom Pusateri <[email-masked]>
Date: Sun, 18 Mar 2018 14:10:59 +0000

Working in the hackathon, I created a simple node javascript client to test DoH.

https://github.com/pusateri/doh-client

This works fine and then Stéphane asked if it could run in the browser. So I did this:

https://github.com/pusateri/doh-webpack

However, when sending a POST to a test server, I am getting a error (400) response to an initial pre-flight OPTIONS request.

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests

The only content types allowed for a POST are:

	• application/x-www-form-urlencoded
	• multipart/form-data
	• text/plain

so a question I have, should the DoH servers respond to a pre-flight OPTIONS method or are things working as designed because this shouldn’t be allowed to run in a browser?

Thanks,
Tom

---

From: Mike Bishop <[email-masked]>
Date: Sun, 18 Mar 2018 14:53:31 +0000

I think the answer is "yes" to both, actually.  A server that wants to answer requests from content on other sites should accept the pre-flight.  But it's working as intended to keep you from firing off DNS requests to arbitrary servers.

Presumably DoH being done by the browser or system, rather than by a webpage itself, wouldn't be subject to these restrictions.

-----Original Message-----
From: Doh <[email-masked]> On Behalf Of Tom Pusateri
Sent: Sunday, March 18, 2018 2:11 PM
To: [email-masked]
Subject: [Doh] Hackathon javascript client & browser issue

Thanks,
Tom

_______________________________________________
Doh mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/doh

---

From: Patrick McManus <[email-masked]>
Date: Sun, 18 Mar 2018 15:09:12 +0000

Layers ahoy!

The rules that govern javascript networking are broadly from xhr/fetch/CORS
(non IETF standards) and these apply to javascript using any HTTP API.
There is nothing particular of DoH, but a browser-js implementation of DoH
is subject to them (as would be accessing a published REST API for
example). In the configuration you describe, the HTTP server is indeed
going to need to whitelist the preflight - but neither the preflight
request or response is itself a DoH request/response.Indeed, they are
literally the pre-flight before the DoH flight.

And its a bit of an aside, but I'm pretty happy with this outcome. It means
DNS is accessible from js-content but only subject to the web's existing
Same-Origin/Cross-Origin security model.. which is something that has known
properties.

-P

On Sun, Mar 18, 2018 at 2:10 PM, Tom Pusateri <[email-masked]> wrote:

> However, when sending a POST to a test server, I am getting a error (400)
> response to an initial pre-flight OPTIONS request.
>
> so a question I have, should the DoH servers respond to a pre-flight
> OPTIONS method or are things working as designed because this shouldn’t be
> allowed to run in a browser?
>
> Thanks,
> Tom
>
>
>
>