Subject: [Doh] POST and GET

From: Sebastiaan Deckers <[email-masked]>
Date: Tue, 18 Sep 2018 11:21:48 +0800

Draft 14, 4.1. The HTTP Request:

> DoH servers MUST implement both the POST and GET methods.

What is meant by the word "implement"?

I have *implemented* both GET and POST code paths. But do they need to
exposed in every use case? I want to be able to support GET only for server
push, for example, and otherwise restrict client requests to POST.

GET requires much more processing from a DOH proxy. I.e. parse the DNS
response packet to find the lowest TTL for HTTP cache-control header
max-age. As an operator I may want to disable support for GET requests from
the client and return 405 or 501.

I love the idea of pushing DNS responses as GET. This is lightweight and
can be easily injected by a DOH proxy. However the current draft, in
section 5.3, does not impose a similar "MUST implement both" requirement on
the client. Should it?

Seb

---

From: bert hubert <[email-masked]>
Date: Tue, 18 Sep 2018 07:16:20 +0200

> What is meant by the word "implement"?

That you implement both methods and that they both work.

> exposed in every use case? I want to be able to support GET only for server

I see no exception or limitation in the text.

> the client and return 405 or 501.

If you do that, you violate the principle of least astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishment
Clients would rightfully be confused. They would also mess it up.

> section 5.3, does not impose a similar "MUST implement both" requirement on

What you are asking for is a sentence that says 'if GET did not work you
must retry as POST'. This complicates every client in existence with
fallback code. DNS is already riddled with fallbacks and retries.

So please no. 

	Bert

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 18 Sep 2018 08:18:11 +0200 (CEST)

> push, for example, and otherwise restrict client requests to POST.

I presume a push should be sent to the client as a GET so that the client gets 
the full request that the response is going to respond to.

> the client and return 405 or 501.

That wouldn't be compliant with the spec.

-- 

  / daniel.haxx.se

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 18 Sep 2018 12:09:06 -0400

On Mon, Sep 17, 2018 at 11:22 PM Sebastiaan Deckers <[email-masked]>
wrote:

> max-age.

It sounds like you want to implement a proxy that operates without any
parsing the DNS response, so it doesn't know the TTL.  This is not
recommended by the specification, but it is allowed.  For correctness, the
only requirement is:

   The assigned freshness
   lifetime MUST NOT be greater than the smallest TTL in the Answer
   section of the DNS response.

Thus, you are permitted to implement GET just as simply as you implemented
POST, by including HTTP headers that disable caching (i.e. result in an
effective freshness lifetime of zero).

> As an operator I may want to disable support for GET requests from the
> client and return 405 or 501.
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>