HttpClient integration

The SDK supports three ownership patterns.

Standalone

using var client = new OkatanaClient(options);

The SDK creates and owns a HttpClient backed by SocketsHttpHandler. Connection pooling is kept stable and the pooled connection lifetime is finite so DNS changes can eventually be observed.

Caller-managed HttpClient

using var http = new HttpClient(customHandler) { Timeout = Timeout.InfiniteTimeSpan };
using var client = new OkatanaClient(http, options);

The caller owns the HTTP client and handler. This is useful for tests, proxies, client certificates, custom DNS behavior, telemetry, and delegating handlers.

IHttpClientFactory

services.AddOkatanaClient(options)
    .SetHandlerLifetime(TimeSpan.FromMinutes(5));

Typed client registration lets .NET manage handler pooling and outgoing middleware. Be careful with broad resilience handlers: the Okatana contract does not make writes idempotent.

Redirect behavior

The standalone client and the default AddOkatanaClient registration disable automatic HTTP redirects. A 3xx response is returned to the SDK and becomes an API error instead of silently moving a request to another URL. This keeps deployment routing explicit and avoids surprising behavior around authenticated requests.

If you replace the primary handler, review its redirect policy. Microsoft documents that .NET handlers enable automatic redirects by default and clear the Authorization header when redirecting. The SDK still validates explicit absolute URLs and server pagination URLs before constructing an authenticated request.

Timeout ownership

The default SDK-created and factory-created HttpClient instances use Timeout.InfiniteTimeSpan. OkatanaClientOptions.Timeout and OkatanaRequestOptions.Timeout therefore control the SDK timeout through a linked cancellation token. If you inject your own HttpClient, its own timeout remains caller-owned and can impose a shorter outer limit.