runtime: Add API to get RST_STREAM value from HTTP exceptions

Part of User Story: https://github.com/dotnet/core/issues/5493

Background and Motivation

gRPC specifies that RST_STREAM error codes are mapped to gRPC error codes - https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#errors

I believe that today the RST_STREAM value is only exposed in exception message descriptions. The only way to get this value is to parse exception messages, which is pretty awful for the usual reasons.

There should be an exception property with the RST_STREAM error code so it can be used programmatically.

Proposed API

Make this value publicly accessible:

https://github.com/dotnet/runtime/blob/faf91e0a7495b70bdae6a8e7109b612a47a74662/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2ProtocolException.cs#L28

I don’t feel strongly that it needs to be an enum. public int ProtocolError { get; } would also be fine.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 21 (21 by maintainers)

Most upvoted comments

This is also related to decision whether to derive QuicException from IOException: https://github.com/dotnet/runtime/issues/56954 In such case, we would have HttpRequestException with IOException as the inner exception in both H/2 and H/3 cases. From that point of view, it might make more sense to reuse the similarity and design a common vehicle for the protocol error code. Moreover, this would also be useful for https://github.com/dotnet/runtime/issues/62228 without sticking HttpRequestException inside IOException (reverse order to what HttpClient does).

This line of thinking depends on the decision we’ll make in #56954. @rzikm, could you please take this into account when you’re thinking about QUIC exceptions?

Either way, as a fallback we can always do what https://github.com/dotnet/runtime/issues/43239#issuecomment-1125131300 above ^ suggests.

Long story short, it looks like we can get away with a simple API addition for this particular issue:

public class HttpRequestException {
    long? ProtocolErrorCode { get; }
}

We can extend this with more error details later if we want. We can utilize it to solve #62228.

@JamesNK here it is in 7.0 😄

@dotnet/ncl can we think of cases when a user would need to see which of the many possible scenarios has resulted in HttpRequestException reporting a protocol error, or are we fine simply adding a field with the error code?

Behold the hack I added to gRPC: https://github.com/grpc/grpc-dotnet/blob/ac3b3f4309b29b0c4fb9048da961e8c054ee955a/src/Grpc.Net.Client/Internal/GrpcProtocolHelpers.cs#L422-L561 😄

It’s not good but it works. Obviously, it would be great to improve with a real API.