The question

Why is forwarding dict(request.headers) from a proxy to an origin both a security bug and a compatibility bug?

Working model

Headers have scope. Proxy-Authorization is a credential for the proxy, not a server selected by the request URL. Connection controls apply to one transport hop. Connection can name additional hop-specific fields, and header names are case-insensitive.

Construct the origin request from an explicit policy: remove proxy credentials and hop-by-hop fields, parse every Connection token, preserve one valid Host, and retain safe end-to-end fields—including repeated fields when their meaning requires it.

Origin Authorization is different from Proxy-Authorization; deleting both is not a safe shortcut.

Provenance

Synthesized from a loopback mmdebstrap proxy regression at Linux Fieldwork revision c79d34b65fb2cd8c54234f361f073248c53b513a. It does not define every extension or CONNECT policy.

Review the request

Decide what reaches the origin:

• Proxy-Authorization: Basic fake-secret
• Authorization: Bearer origin-token
• Connection: keep-alive, X-Hop
• X-Hop: local-only
• Range: bytes=0-1023

Then state what a real loopback-origin test can prove that a helper-unit test cannot.