Re: [Doh] Support requirements for Get and Post

[Ben Schwartz <[e-mail]>]

So does that mean that a DOH server and client that both comply with all
SHOULD-strength requirements still may not be able to exchange any DNS
data?  That seems like a weaker guarantee of compatibility than is typical
at the IETF.

If following all the SHOULD-level recommendations is not sufficient to
ensure compatibility, then as an implementor I would appreciate some clear
additional guidance on what I have to do to make my client compatible with
any compliant DOH server (and vice versa as a server implementor).

On Sat, Mar 17, 2018 at 2:30 PM, Patrick McManus <[e-mail]>
wrote:

> imo normative SHOULD is a tad too strong.
>
> One thing to note is that the 405 ought to include an allow response
> header indicating what methods it can process.. so your fallback ought to
> be in that set, at a minimum.
>
> But its also possible that the other method might not meet your
> requirements.. e.g. a GET is 405'd and you require an HTTP cache to meet
> performance requirements - you might not use doh, or use a different
> server, or whatever instead of SHOULD retry.
>
> may is really ok imo.
>
>
>
> On Sat, Mar 17, 2018 at 5:22 PM, Ben Schwartz <[e-mail]> wrote:
>
>> On Sat, Mar 17, 2018 at 9:47 AM, Patrick McManus <[e-mail]>
>> wrote:
>>
>>> Overall I think the draft does an OK job of describing the merits of
>>> get/post (post is more efficient but is not http cache friendly, get is
>>> needed for cases like push and is more http cache friendly). If folks think
>>> its imperative to have that summary in one place in the document I'm happy
>>> to make that change.
>>>
>>> I would think most clients relying on http caches for performance would
>>> use get, but if they have a DNS cache they are populating they would use
>>> post. A server can choose not to implement one of these (and "method not
>>> allowed" is the right response for that imo), but its limiting what clients
>>> can achieve with it.
>>>
>>
>> SHOULD clients handle a "method not allowed" by retrying with the other
>> method?
>>
>>
>>>
>>> -P
>>>
>>>
>>> On Sat, Mar 17, 2018 at 1:43 PM, Patrick McManus <[e-mail]>
>>> wrote:
>>>
>>>> push #1: anticipate other needs of the client (as mentioned)
>>>>
>>>> push #2: its a different way to express additional records if that's a
>>>> desirable thing (e.g. ttl granularity)
>>>>
>>>>
>>>>
>>>> On Sat, Mar 17, 2018 at 1:16 PM, Ólafur Guðmundsson <
>>>> [e-mail]> wrote:
>>>>
>>>>> What is the usage case to Server push of DNS answers ?
>>>>>
>>>>> Olafur
>>>>>
>>>>>
>>>>> On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> On Sat, 17 Mar 2018, Ólafur Guðmundsson wrote:
>>>>>>
>>>>>> Post MUST be supported Get MAY be supported, when GET is not
>>>>>>> supported the error code retuned should be 405 (HTTP RFC 7321, section
>>>>>>> 6.5.5).
>>>>>>>
>>>>>>
>>>>>> You didn't say this, and it is a side-note about methods, but I still
>>>>>> wanted to just mention that when imlementing support for HTTP/2 server push
>>>>>> for DOH, you want the server to send that as a GET so that the query string
>>>>>> tells the client about the request it also sends the response to...
>>>>>>
>>>>>> --
>>>>>>
>>>>>>  / daniel.haxx.se
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Doh mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/doh
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Doh mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/doh
>>>
>>>
>>
>