txthinking/brook · warning
err.Error()
Error message
err.Error()
What it means
DOHServer.ServeHTTP reads the entire request body before treating it as a DNS message. If io.ReadAll fails (client aborted mid-upload, body stream error, timeout), the server responds with HTTP 500 carrying the underlying error text. The error message is dynamic - it is whatever io.ReadAll returned.
Source
Thrown at dohserver.go:164
Retry: 3600,
Expire: 259200,
Minttl: 300,
})
m1b, err := m1.PackBuffer(nil)
if err != nil {
return false, err
}
w.Header().Set("Content-Type", "application/dns-message")
w.Write(m1b)
return true, nil
}
return false, nil
}
func (s *DOHServer) ServeHTTP(w http.ResponseWriter, r *http.Request) {
b, err := io.ReadAll(r.Body)
if err != nil {
http.Error(w, err.Error(), 500)
return
}
m := &dns.Msg{}
if err := m.Unpack(b); err != nil {
http.Error(w, err.Error(), 500)
return
}
done, err := DOHGate(m, w, r)
if err != nil {
http.Error(w, err.Error(), 500)
return
}
if done {
return
}
m1 := &dns.Msg{}
if s.DNSClient != nil {
m1, err = s.DNSClient.Exchange(m)View on GitHub (pinned to 5cd13ef3b1)
Solutions
- Retry the DNS query from the client with an intact connection
- Check client-side timeouts and keep-alive settings so the body completes
- Verify no intermediary (proxy/LB) terminates long uploads; raise its body/timeout limits
- Inspect the specific error text in the 500 response to target the root cause (reset vs timeout)
- Consider sending the query via GET (RFC 8484 ?dns= parameter) to avoid upload truncation
Defensive patterns
Strategy: retry
Try / catch
resp, err := http.Post(dohURL, "application/dns-message", body)
if err != nil || resp.StatusCode == 500 {
// transient body/read failure: rebuild query and retry with backoff
time.Sleep(backoff); retry()
} Prevention
- Use client timeouts longer than worst-case upload time
- Prefer GET with ?dns= for small queries
- Avoid uploading large bodies over flaky links
When it happens
Trigger: A DoH POST whose body stream breaks: client disconnects before the full body arrives, connection reset, body larger than the server's read limits, or network interruption during upload.
Common situations: Mobile clients dropping connections mid-request; aggressive client timeouts smaller than upload time; load balancer cutting the connection; malformed chunked transfer encoding.
Understand the failure class
Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.
Related errors
AI-assisted analysis of txthinking/brook@5cd13ef3b1 (2026-09-06).
Data as JSON: /api/errors/de4fd39d844ca22c.
Report an issue: GitHub.