fix(java,csharp): personal access token name is not escaped in the HTTP delete path #4672

Bug description

The Java and C# HTTP clients build the delete path for a personal access token by pasting the name in as is:

• Java: PersonalAccessTokensHttpClient.java:56, PERSONAL_ACCESS_TOKENS + "/" + name
• C#: HttpMessageStream.cs:921, $"/personal-access-tokens/{name}"

Expected: any valid token name goes out as one path segment, so the DELETE removes the token with that name.

Actual: the URL library normalizes the path, so some names hit another URL:

The caller acts as themselves, so this is not a privilege problem. It deletes the wrong token or hits the wrong endpoint.

The Rust SDK had the same bug and is fixed in #4628 (encode_segment). The C++ and Python SDKs wrap the Rust SDK, so they get that fix. Java and C# have their own HTTP code and need their own.

. and .. need extra care. An encoded %2E%2E is still resolved as a dot segment by the URL parser (checked with Rust's url crate: .. sends DELETE /), so they should be rejected before sending. The server only checks the name length, so a token named .. can be created over TCP but not deleted over HTTP.

Affected area / component

Java SDK, C# SDK

Versions

master at d6e42a7cd

Hardware / environment

macOS, local

Sample code

var url = new Uri(new Uri("http://127.0.0.1:3000/"), "/personal-access-tokens/../users/42");
Console.WriteLine(url.AbsolutePath); // /users/42

Reproduction

1. Log in with the Java or C# client over HTTP.
2. Call deletePersonalAccessToken / DeletePersonalAccessTokenAsync with ../users/42.
3. The request goes to DELETE /users/42 instead of the token route.

Checked so far: Rust (url crate) and C# (System.Uri) give the table above. For Java I only checked java.net.URI.normalize(), not the real HTTP client. I have not run a live delete against a server.

Contribution

• I'm willing to submit a pull request to fix this bug