Skip to content

feat: Hot Rod URI support — RemoteCache::fromUri (issue #9) - #11

Merged
rigazilla merged 1 commit into
mainfrom
feat/hotrod-uri
Oct 21, 2026
Merged

rigazilla merged 1 commit into
mainfrom
feat/hotrod-uri

Conversation

@rigazilla

@rigazilla rigazilla commented Oct 9, 2026 •

Copy link
Copy Markdown
Member

Closes #9.

What this adds

A connection-string entry point:

auto cache = RemoteCache::fromUri(
    "hotrod://user:pass@node1:11222,node2:11222"
    "?sasl_mechanism=SCRAM-SHA-256&client_intelligence=hash_distribution_aware",
    "my-cache");
cache->connect();

Parsing lives in a pure, header-only HotRodURI::parse (include/hotrod/HotRodURI.h, following the ServerSelection.h / AuthCodec.h precedent). The factory applies the existing flat setters and returns a configured, not-yet-connected std::unique_ptr<RemoteCache> (RemoteCache owns a mutex, so it is non-movable).

Behaviour follows the Java client HotRodURI (authoritative per AGENTS.md), not the .NET docs linked from the issue — notably protocol_version uses Java's "4.0"/"4.1" form, not version40.

Scope — this PR is focused on URI parsing only

It parses the whole URI but wires up only what the client supports today, and throws a clear HotRodClientException for anything else:

Supported (v1): hotrod:// scheme; [user:password@]; comma-separated host[:port] (first host seeds the topology, discovery finds the rest); query whitelist sasl_mechanism, client_intelligence (case-insensitive), protocol_version (4.0/4.1).

Rejected with an explicit error (not silently ignored): hotrods:///TLS, unknown params (connect_timeout, socket_timeout, use_ssl, token, …), protocol_version=AUTO/3.x.

The missing pieces are intentionally out of scope and all tracked as follow-up issues — see #10 (TLS/hotrods://, timeouts, multi-server seed failover, non-SCRAM SASL, AUTO/3.x versions). Each will drop its "unsupported" throw as the underlying capability lands.

Tests

  • Unit — +20 (HotRodURITest): grammar, multi-host, userinfo, the typed query whitelist, and explicit rejection of the deferred features. Full unit suite 243/243; Release -Werror build clean. Parsing is pure, so this is the exhaustive coverage.
  • Integration — +3, suite now 92/92 across 19 suites (verified live): FromUriIntegrationTest (plain hotrod:// round-trip; a ?protocol_version=4.0 client flows the param through to a working client) and AuthIntegrationTest.FromUriWithCredentialsAuthenticates (credentials + ?sasl_mechanism in the URI authenticate end-to-end). These prove the parse→setter→connect→op chain.
    • Note: client_intelligence=hash_distribution_aware is deliberately not integration-tested on the single-server fixture (the Dockerized single node advertises internal container addresses, so hash-aware routing is covered only by the multi-server suites). The single-server URI test uses the routing-neutral protocol_version instead.

Docs updated alongside the code (STATUS.md / DECISIONS.md / README.md).

🤖 Generated with Claude Code

@rigazilla
rigazilla force-pushed the feat/hotrod-uri branch 2 times, most recently from 1f0c828 to 580161e Compare October 9, 2026 15:48
Add a connection-string entry point requested in issue #9:

  RemoteCache::fromUri("hotrod://[user:pass@]host1[:port1][,host2...][?k=v&...]")

Parsing lives in a pure, header-only HotRodURI::parse (include/hotrod/HotRodURI.h,
following the ServerSelection.h / AuthCodec.h precedent); the factory applies the
existing flat setters and returns a configured, not-yet-connected
unique_ptr<RemoteCache> (RemoteCache owns a mutex, so it is non-movable).

Behaviour follows the Java client HotRodURI (AGENTS.md source order), not the
.NET docs the issue links — notably protocol_version uses Java's "4.0"/"4.1"
form. v1 scope: hotrod:// only; first host seeds the topology; credentials enable
SCRAM; query whitelist sasl_mechanism / client_intelligence / protocol_version.
Anything unsupported (hotrods:// / TLS, unknown params, AUTO/3.x versions) throws
a HotRodClientException; deferred features tracked in issue #10.

Userinfo and query values are percent-decoded (RFC 3986), matching the Java
client's java.net.URI parsing, so a reserved character in a password (e.g. an
'@' written %40) reaches SCRAM as its real bytes instead of failing auth.
Malformed escapes throw; decoding happens after the raw user:pass split so an
encoded ':' in the password is preserved.

Tests: +27 unit (HotRodURITest), full suite 250/250, Release -Werror clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@rigazilla
rigazilla merged commit f9d518e into main Oct 21, 2026
3 checks passed
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.

Support Hot Rod URIs

1 participant