Skip to content

Encode path parameter properly to handle characters like |#699

Open
Divyansh-db wants to merge 2 commits intomainfrom
divyansh-vijayvergia_data/fix-path-parameter-encoding
Open

Encode path parameter properly to handle characters like |#699
Divyansh-db wants to merge 2 commits intomainfrom
divyansh-vijayvergia_data/fix-path-parameter-encoding

Conversation

@Divyansh-db
Copy link
Contributor

@Divyansh-db Divyansh-db commented Mar 11, 2026

Summary

Fixes Request.java to preserve percent-encoding on path parameters, unblocking the codegen-side fix for APIs that
interpolate resource names with URI-unsafe characters (e.g., | in table names).

Why

When a customer calls an API like tables().get() with a resource name containing characters like |, ?, #, [, or ],
the request fails with java.lang.IllegalArgumentException: Illegal character in path. This is because generated
*Impl.java files pass path parameters into String.format without percent-encoding — a table named
catalog.schema.name|here produces the raw path /api/2.1/unity-catalog/tables/catalog.schema.name|here, and Java's URI.create() rejects it.

The full fix requires the code generator to wrap string path parameters with Encoding.encodeMultiSegmentPathParameter() (the same pattern FilesImpl has used since v0.22.0). However, even after that codegen change, two bugs in Request.java would silently decode the encoded values back to their raw form, re-introducing the failure. This PR fixes those bugs so that once the codegen change lands, encoding is preserved end-to-end.

What changed

Interface changes

None.

Behavioral changes

  • Request.getUri() now preserves percent-encoded path segments (e.g., %7C stays as %7C) when appending query parameters. Previously, paths like /tables/name%7Chere would be decoded back to /tables/name|here during URI reconstruction, causing URI.create() to throw.
  • Request.getRequestLine() now returns the raw (encoded) path and query in log output and toString(), consistent with what is sent on the wire.

Internal changes

  • Request.getUri(): changed uri.getPath() → uri.getRawPath() on the line that reconstructs the URI string when query params are present. getPath() decodes percent-encoded sequences; getRawPath() does not.
  • Request.getRequestLine(): changed uri.getPath() → uri.getRawPath() and uri.getQuery() → uri.getRawQuery() for the same reason.
  • Expanded EncodingTest with table-driven cases covering |, ?, #, [, ], spaces, braces, sub-delim preservation, and
    the exact customer table name from the incident.
  • Rewrote RequestTest as table-driven parameterized tests covering getUri() and getRequestLine() with encoded paths, query param merging, and full URLs.

How is this tested?

  • 21 new parameterized test cases across EncodingTest and RequestTest verifying encoding preservation throug the full Request → URI pipeline.
  • Full test suite passes (1108 tests, 0 failures).
  • Not tested end-to-end against a live workspace — that requires the companion codegen change to actually encode path parameters in generated *Impl.java files.

NO_CHANGELOG=true

@github-actions
Copy link

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/sdk-java

Inputs:

  • PR number: 699
  • Commit SHA: 8b1e3a15736b7a579d20cdce7cdad622850aec9f

Checks will be approved automatically on success.

@Divyansh-db Divyansh-db changed the title Do not decode the encoded path parameter Encode path parameter properly to handle characters like | Mar 13, 2026
@Divyansh-db Divyansh-db requested a review from rauchy March 13, 2026 12:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant