A 301, 302 or 303 answer sends the reporting key to the redirect target as an empty GET #31

urllib.request.urlopen follows redirects, so a 301, 302 or 303 answer to a report re-sends the Authorization header to the Location target, including a target on another host, as a GET with no body.

Reproduced on Python 3.8.10 with an origin on 127.0.0.1 redirecting to a target on localhost, a different port:

Three consequences follow:

• The reporting key is disclosed to whatever host a redirect names. The key is scoped to reporting only (README, "Keys"), which limits the damage but does not remove the disclosure.
• The event is lost either way, and the log names the target's status, not the redirect that lost it.
• The clients differ. The trace-client-java README says "Redirects are not followed": a redirect is logged and the report dropped. The Python README's wire format section says nothing about redirects, while it promises the two clients speak the same wire format.

The 307/308 row depends on the interpreter: HTTPRedirectHandler gained 308 handling in Python 3.11, so the result on 3.12 may differ and has not been checked here.

Suggested fix: open the request through an opener whose redirect handler declines to follow, so that a redirect reaches the existing non-201 log line, and add the Java README's redirect paragraph to the wire format section. This changes _send's behaviour on the wire, so it is a change for the owner to review, not one for autonomous merge.

This issue was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).

drafted by Claude on behalf of Daniel Stephenson