grpc-dotnet + Blazor sets Safari and Firefox User-Agent to "grpc-dotnet/$assemblyVersion"

[LukasReschke]

Describe the bug

When using grpc-dotnet and Blazor together to call a GRPC API, the User-Agent is set to "grpc-dotnet/$assemblyVersion" in Safari and Firefox. In Chrome and Edge it is the actual browser User-Agent.

https://docs.microsoft.com/en-us/aspnet/core/grpc/services?view=aspnetcore-5.0 for example describes how to read the User-Agent:

public override Task<ExampleResponse> UnaryCall(ExampleRequest request, ServerCallContext context)
{
    var userAgent = context.RequestHeaders.GetValue("user-agent");
    // ...

    return Task.FromResult(new ExampleResponse());
}

(Migrated from dotnet/AspNetCore.Docs#21178)

To Reproduce

Use GRPC with Blazor as described at https://docs.microsoft.com/en-us/aspnet/core/grpc/browser?view=aspnetcore-5.0 and look at the traffic in Safari. The User-Agent will be for example "grpc-dotnet/2.34.0.0".

You can also check out https://our.gatekeeper.page in Safari or Firefox and look at the request to the "WhoAmI" endpoint to see the header being wrong. The code for this can be found at https://github.com/getgatekeeper/server.

The Blazor example from https://github.com/grpc/grpc-dotnet/tree/master/examples/Blazor should also have the same issue.

The issue seems potentially related to the following piece of code in Grpc.Net.Client/Internal/GrpcCall.cs. I wonder if Chrome/Edge just ignore the header being overwritten whilst Safari and Firefox obeys it:

// User agent is optional but recommended.
headers.TryAddWithoutValidation(GrpcProtocolConstants.UserAgentHeader, GrpcProtocolConstants.UserAgentHeaderValue);

Test plan

Browser	Sends correct User-Agent	Screenshot
Safari	❌
Firefox	❌
Chrome	✅
Edge	✅

[JamesNK]

Thanks for the detailed issue. I'll investigate what the client should do here.

@BrennanConroy Does the SignalR JS client set a user-agent?

[JamesNK]

It appears the gRPC-Web JS client sets x-user-agent: https://github.com/grpc/grpc-web/blob/2e3e8d2c501c4ddce5406ac24a637003eabae4cf/javascript/net/grpc/web/grpcwebclientbase.js#L323

[BrennanConroy]

SignalR sets the "X-SignalR-User-Agent" header.

aspnetcore/src/SignalR/clients/ts/signalr/src/Utils.ts

Line 201 in 020145d

let userAgentHeaderName = "X-SignalR-User-Agent";

I believe the reason we don't set "User-Agent" is because it used to be a forbidden header but no longer is. Also, Chrome just drops the header? https://bugs.chromium.org/p/chromium/issues/detail?id=571722

[BrennanConroy]

Oh, I guess this is about WASM, in the .NET client we set the User Agent

aspnetcore/src/SignalR/clients/csharp/Http.Connections.Client/src/HttpConnection.cs

Line 597 in 020145d

httpClient.DefaultRequestHeaders.Add(Constants.UserAgent, Constants.UserAgentHeader);

But you can provide a User Agent header to overwrite. And an empty string will remove the header we set.

aspnetcore/src/SignalR/clients/csharp/Http.Connections.Client/src/HttpConnection.cs

Line 605 in 020145d

if (string.Equals(header.Key, Constants.UserAgent, StringComparison.OrdinalIgnoreCase))

[JamesNK]

Does SignalR .NET library also run in Blazor WASM? If so, I wonder if gRPC and SignalR .NET libraries should have special logic for how they set headers in Blazor WASM.

@pranavkm Is there a way for a library to detect whether it is running inside the browser? Like something on Environment e.g.

if (!IsBlazorWasm)
{
    headers.Add("user-agent", "library/1.2");
}
else
{
    // Don't set user-agent when calling from the browser. It is a protected header in Chrome/Edge.
    headers.Add("x-user-agent", "library/1.2");
}

[BrennanConroy]

Yes it runs in the browser, you can use OperatingSystem.IsBrowser()

aspnetcore/src/SignalR/clients/csharp/Http.Connections.Client/src/HttpConnection.cs

Line 155 in 020145d

if (httpConnectionOptions.Transports == HttpTransportType.ServerSentEvents && OperatingSystem.IsBrowser())

https://github.com/dotnet/aspnetcore/blob/2ceca7fb89a4021166b32f18612bc490d3146fe2/src/Shared/OperatingSystem.cs

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[JamesNK]

gRPC fixed. Re-opening for SignalR.