Resolvers such as Cloudflare always add padding to DoH responses
Resolvers such as Google only do if the question had dumb padding
Resolvers such as Cisco blindly return a copy of the question's padding
Some resolvers don't return any padding no matter what's in the question
Finally, other resolvers return FORMERR
This is a mess. A bad design inherited from DoT, that didn't fix
anything from Unbound's original experiment.
Also, padding with zeros as recommended is a bad idea. When using
GET, escaping makes the actual padding size 3 times as big as needed.
This mechanism is horrible, slow (requires re-unpacking and re-packing
the query), should be done at transport layer and not at content layer, and
of course, it is incompatible with some resolvers.
However, in spite of https://go-review.googlesource.com/c/go/+/114316/2/src/net/http/transfer.go ,
we may still end up sending the header and the content in distinct packets.
So, use that horror for POST queries only. For GET, this is not needed.
* 'master' of github.com:jedisct1/dnscrypt-proxy:
CI: don't hardcode the HTTP port
2.0.36-beta.1
agl/ed25519 is not required any more
CI: Change the local DoH port, run go tests, enable -race
I noticed while writing the functionality tests that comments about relative paths disagreed with what the code was doing.
While the executable directory is used if the configuration file itself can't be found, `cdFileDir(foundConfigFile)` is always executed after the configuration file is found whether that's the same as the executable's directory or not.
Also a couple of punctuation nits.
I'm not sure why an extra "dnscrypt-proxy" was added to the module name when the rest of the URL was updated, but it resulted in the following:
```
$ go test -mod=vendor ./...
ok github.com/DNSCrypt/dnscrypt-proxy/dnscrypt-proxy/dnscrypt-proxy 0.173s
ok github.com/DNSCrypt/dnscrypt-proxy/dnscrypt-proxy/test 0.006s
$ go list ./...
github.com/DNSCrypt/dnscrypt-proxy/dnscrypt-proxy/dnscrypt-proxy
github.com/DNSCrypt/dnscrypt-proxy/dnscrypt-proxy/test
```
Not critical, but it looks wrong that these packages will not be found at those URLs.
We now enforce the fact that a query always include a question.
It holds true for all practical use cases of dnscrypt-proxy.
This avoids quite a lot of redundant code in plugins, and is faster.