Only set AutomaticDecompression when the platform supports it

[thelocalsim]

Fixes #77.

The problem

Constructing an EsiClient under Blazor WebAssembly fails immediately, before any request is made:

Error: One or more errors occurred. (Operation is not supported on this platform.)

EsiClient's default handler set AutomaticDecompression unconditionally:

client = _client ?? new HttpClient(new HttpClientHandler
{
#if NET
    AutomaticDecompression = DecompressionMethods.All
#else
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
#endif
});

@AdmirableTable identified this line in the issue thread and confirmed empirically that removing the assignment clears the error. The runtime side matches: in dotnet/runtime, HttpClientHandler.AutomaticDecompression carries [UnsupportedOSPlatform("browser")] and delegates to the underlying handler, and the browser implementation throws from both accessors:

public DecompressionMethods AutomaticDecompression
{
    get => throw new PlatformNotSupportedException();
    set => throw new PlatformNotSupportedException();
}

The browser's fetch API performs content decoding itself and exposes no way to configure it, which is why the property is unsupported rather than merely ignored.

The fix

Guard the assignment with HttpClientHandler.SupportsAutomaticDecompression. The same browser handler declares it as a compile-time constant:

public const bool SupportsAutomaticDecompression = false;

It is a plain bool getter that never throws, so it is safe to call on every platform, and it is present in all nine target frameworks this project builds for — netstandard2.0, net462/net47/net471/net472/net48, netcoreapp3.1, net6.0, net7.0 — so the guard itself needs no conditional compilation.

Handler construction moves into a small private factory, so a handler is still only allocated when the caller does not supply their own HttpClient.

Behaviour

• Unchanged on every platform that supports decompression. The existing #if NET split between DecompressionMethods.All and GZip | Deflate is preserved verbatim, including the linked sso-issues#81 comment explaining the brotli change.
• Blazor WebAssembly now constructs successfully; the browser handles gzip/deflate/brotli transparently.
• No public API change.

A note on verification

I do not have a Blazor WebAssembly environment to hand, so I have not run the fix end to end — the diagnosis rests on the reporter's confirmation plus the runtime source above, and the fix follows the capability-probe pattern those Supports* properties exist for. The repository has no test project and I had no .NET SDK available locally to compile-check the multi-target build, so please let CI confirm the build across all nine TFMs. Happy to adjust if anything falls out.

I deliberately kept this minimal and did not take the RestSharp replacement suggested in the issue thread — that is a much larger dependency and API change, and this bug does not require it.

🤖 Generated with Claude Code