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

  1. Retry the DNS query from the client with an intact connection
  2. Check client-side timeouts and keep-alive settings so the body completes
  3. Verify no intermediary (proxy/LB) terminates long uploads; raise its body/timeout limits
  4. Inspect the specific error text in the 500 response to target the root cause (reset vs timeout)
  5. 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

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.