René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Deprecate Builder.customizeRequest() in favor of httpRequestCustomizer()","articleBody":"**Bug description**\n\n`Builder.customizeRequest()` in both `HttpClientSseClientTransport` and `HttpClientStreamableHttpTransport` executes its consumer **once at build time**, mutating the shared `requestBuilder`. Any headers set here (e.g., `Authorization`) are frozen into the template and copied to every subsequent request via `requestBuilder.copy()`. They cannot be updated after the transport is built.\n\nThis becomes a significant issue for OAuth token refresh scenarios: after refreshing an access token, the transport continues sending the **old expired token** because the header was baked into the request builder at construction time.\n\nThe method name `customizeRequest` strongly suggests per-request behavior, making it easy to use incorrectly. The correct alternatives — `httpRequestCustomizer()` and `asyncHttpRequestCustomizer()` — already exist and run on every request, but there's no deprecation notice guiding users toward them.\n\n**Environment**\n\nMCP Java SDK (latest main branch). Affects both `HttpClientSseClientTransport` and `HttpClientStreamableHttpTransport`.\n\n**Steps to reproduce**\n\n```java\nvar transport = HttpClientSseClientTransport.builder(baseUri)\n    .customizeRequest(builder -\u003e {\n        // This runs ONCE at build time — token is frozen\n        builder.header(\"Authorization\", \"Bearer \" + tokenProvider.getAccessToken());\n    })\n    .build();\n\n// Later: token expires, tokenProvider returns a new token\n// But all requests still carry the old token from build time\n```\n\n**Expected behavior**\n\nUsers should be guided toward `httpRequestCustomizer()` or `asyncHttpRequestCustomizer()` for dynamic headers. Ideally, `customizeRequest()` should be marked `@Deprecated` with clear Javadoc explaining the build-time-only semantics.\n\n**Real-world impact**\n\nWe encountered this in production where our MCP connector's OAuth token refresh was completely non-functional:\n\n1. Access token expires → server returns 401\n2. Connector successfully refreshes the token (new token stored)\n3. Connector retries with the same transport (no re-creation, since `McpAsyncClient` is already initialized)\n4. But `requestBuilder` still has the old token baked in from build time\n5. Retry sends the old expired token → 401 again → permanent failure\n\nSwitching from `customizeRequest()` to `httpRequestCustomizer()` resolved the issue.\n\n**Additional note**\n\nThe current Javadoc for `customizeRequest()` says *\"Customizes the HTTP client builder\"* which is also slightly misleading — it customizes the request builder, not the client builder (that's `customizeClient()`).\n\nA PR with the deprecation annotation and updated Javadoc has been submitted: #791","author":{"url":"https://github.com/gyeo009","@type":"Person","name":"gyeo009"},"datePublished":"2026-02-13T12:44:31.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/788/java-sdk/issues/788"}