Re: [Doh] Hackathon javascript client & browser issue

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 <pusateri@bangj.com> wrote:

> 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
>
>
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>