I found a discussion on HTTP GET with request body: http://stackoverflow.com/questions/978061/http-get-with-request-body
Generally, it is not encouraged using GET with request body in this conversation. It is said that rfc2616#section-4.3 recommends server toignore undefined entity-body. But rfc7230#section3.3 did not recommend that server behavior. another reason is library support varies on supporting GET with payload. For pure "Aesthetics" reason, If I was designing a toy protocol or a custom tool, then I might insist on GET. but I should choose POST to work around broken software and proxy in the networks. On Wed, Mar 2, 2016 at 6:04 PM, Davey Song <songlinj...@gmail.com> wrote: > 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
