James Newton-King

Grpc uses pipelines in asp.net core server and Stream in the client.

HttpClient uses Stream in its APIs. Pipelines would be another layer of abstraction that wouldn’t add any value. One of the nice things about pipelines is it manages buffer pooling...

Currently yes. Agree that won't be best for big messages. Might look at using an `IBufferWriter` implementation that splits big messages into buffer segments.

Background: I've looked at HTTP2 headers a lot. I wrote some of the dynamic support and rewrote the writer and parser at one point. I haven't looked through the code...

I don't think we need a switch. If this lands in a mid .NET 9 preview, then it should go through a lot of use and testing before GA. For...

@samsp-msft There is prior art for showing more error info in [`error.type`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/error/). That tag is already on HTTP requests for server and client in spans and metrics. Reducing error info...

I think a small snippit of code in this section - https://learn.microsoft.com/en-us/aspnet/core/grpc/health-checks?view=aspnetcore-8.0#call-grpc-health-checks-service - is enough. e.g. configure the client ```cs builder.Services .AddGrpcClient(o => { o.Address = new Uri("https://localhost:5001"); }) ```...

This is done in the OpenAPI integration for gRPC JSON transcoding: https://learn.microsoft.com/en-us/aspnet/core/grpc/json-transcoding-openapi?view=aspnetcore-7.0

This is in 2.52.0-pre1, which is on NuGet now. Non-preview release will be in a week, or maybe two.

https://github.com/grpc/grpc-dotnet/pull/2021 updates the dependencies to .NET 6