According to RFC7231 (section 4.3.1), payload is not defined for GET and GET request with payload will be reject by some implementation (like google app engine) . It is not say GET should not use a request payload. the draft actually propose a new payload definition for DNS over HTTP scenario. Right?
On Wed, Mar 2, 2016 at 11:08 AM, P Vixie <p...@redbarn.org> wrote: > We did not use get because get does not have a request payload. > > On March 1, 2016 6:44:16 PM PST, Davey Song <songlinj...@gmail.com> wrote: > >> >> >> On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman <paul.hoff...@vpnc.org> >> wrote: >> >>> This document is a good idea, but it has some faults that need to be >>> fixed before it goes forwards. >>> >>> - In the Introduction, it says in essence that this is just using HTTP >>> to tunnel DNS and is not of use to web browsers. This is wrong, I believe. >>> JavaScript in browsers cannot create port 53 queries, but they can create >>> arbitrary HTTP/HTTPS queries. This protocol would allow JavaScript apps to >>> get DNS responses as long as they could cobble together the request bytes >>> and interpret the response. It would be ugly, yes, but so is a lot of stuff >>> I see in JavaScript these days. >>> >>> If it is feasible (or there is an technical requirement) that JavaScript >> can handle wire-format DNS massage over HTTP, it is no reason to exclude >> it. So the simple way to edit this is to get rid of such saying of denying >> web browser user. >> >> >>> - Using POST for queries goes against the design of HTTP. POST is for >>> requests that change state on the server, and DNS queries are not that. >>> This protocol should use GET. >>> >> Fair enough. >> >>> >>> - The lack of a common URI template will completely prevent >>> interoperability. You should instead use .well-known prefix for getting the >>> syntax as described in RFC 5785. >>> >> I agree we should end up with a fixed URI template which can be >> recognized by both client and server. Particularly in Proxy mode, the >> server proxy will leverage the 80/443 port with existing Web server, we >> should avoid conflicts with existing web service URIs. >> >> - Section 3.3 is completely unclear. Either prohibit the two-byte length >>> added for TCP queries, or require them all the time. Making them optional >>> will make interoperability difficult or impossible. >>> >> >> What we say in Section 3.3 is not including the two-byte field in the >> message sent to the server. Is the text not clear ? I will try to make it >> more clear >> >>> >>> - Having no security considerations for a protocol that has optional >>> HTTPS seems like a big oversight. >>> >> Yes. I admit it is a big oversight here. I will discuss with co-authors. >> Any suggestions ? >> >>> >>> Hope this helps! >>> >>> Thank you ! The original idea is to document how we implement the >> software and try to share the communication pattern with other developers. >> Now we should follow IETF way to formalized the document : ) >> >> Davey >> >>> --Paul Hoffman >>> >> >> ------------------------------ >> >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
