What Does This Do

Draft / jumping-off point, expect to iterate.

Stops HttpURLConnection requests with common bad-input URLs from throwing and reporting a URISyntaxException on every request.

java.net.URL accepts strings that java.net.URI rejects. HttpUrlConnectionDecorator.url and UrlConnectionDecorator.onURL called URL.toURI(), so each such request threw, was caught in HttpClientDecorator.onRequest ("Error tagging url"), and ended up with no http.url, no peer host/port, and no path-based resource name.

• Adds URIUtils.toURI(URL), which percent-encodes only what java.net.URI rejects before parsing: a space or control character, any of " < > \ ^ { | }, [or]in the **path** (they stay legal in the query, fragment and an IPv6 host), a%not followed by two hex digits, and a second#`. Non-ASCII letters are kept; non-ASCII spaces/controls are encoded as UTF-8.
• Well-formed URLs are converted exactly as url.toURI() would, and return the same String with no extra allocation.
• Anything else URI rejects still throws URISyntaxException, so existing catch blocks behave as before.
• HttpUrlConnectionDecorator.url and UrlConnectionDecorator.onURL now use it.
• Adds URIUtilsToURITest (JUnit 5, 17 cases): repaired inputs, unchanged well-formed inputs (compared with url.toURI()), non-ASCII handling, and a case that must still throw.

Motivation

Three Error Tracking issues are this same failure through different entry points: 7eb5eb3c (HttpURLConnection.getInputStream), 80a09d2a (HttpURLConnection.connect, currently IGNORED with no recorded reason) and 7d87bb46 (commons-httpclient, not touched here). Together they are about 200k events a day (all tracer versions; reports aggregate repeats, so the real throw count is higher), and 80a09d2a is still ~28% on 1.65.1 / 1.66.0, so upgrading does not make it go away. A latch is the wrong tool because the failure is per URL, so the fix makes the failing case cheap instead of skipping it. Related: APMLP-1881 (guarded safeParse) and APMLP-1884 (input-rate breaker and per-site counters).

Additional Notes

• No benchmark included. The claim is that a repaired URL costs less than a thrown and caught URISyntaxException plus the lost tags; that is reasoned, not measured. A JMH comparing the three paths (well-formed, repaired, throwing) would be a good addition before this leaves draft.
• Behavior change to be aware of: requests that used to get no URL tags now get them, built from the repaired URI. http.url and the SSRF check see the percent-encoded form, and URI.getPath() decodes back to the original characters.
• Possible iterations:
  • The pathStart / path-end scan runs on every call and is only needed when the string has a [ or ]; computing it lazily would make the clean path a single pass (techdebt noted this; perf-review did not consider it worth flagging).
  • Other toURI() callers were not touched: OkHttpClientDecorator (okhttp-2.2, request.url().toURI()), and commons-httpclient (new URI(httpMethod.getURI().toString()), a different source type).
  • The structural alternative is a client-side URIDataAdapter (already used by ~20 server decorators) so that nothing goes through the strict java.net.URI.
• java.net.URL already rejects malformed authorities at construction, so URI failures after the repair should be rare; the "still throws" test uses the multi-argument URL constructor, which does not validate the host.
• SpotBugs and Spotless pass on internal-api and agent-bootstrap. CI has not run.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: N/A

🤖 Generated with Claude Code