Problem
.NET exposes HTTP response trailer fields through HttpResponseMessage.TrailingHeaders, but RestSharp currently maps only the regular response headers and content headers to RestResponse. The internal HttpResponseMessage is disposed after execution, so callers using the standard ExecuteAsync path cannot access trailer fields.
Trailer fields are useful for message integrity checks, signatures, delivery metrics, and post-processing status information. RFC 9110 also recommends storing them separately from the initial header section.
Proposed change
- Add a TrailingHeaders collection to RestResponseBase, separate from Headers and ContentHeaders.
- Populate it after the response body has been fully consumed, because .NET exposes received trailers only after content completion.
- Keep the collection empty on target frameworks where HttpResponseMessage.TrailingHeaders is unavailable.
- Add tests verifying that trailers are preserved and remain separate from regular headers.
Compatibility
This would be an additive public API change. RestSharp targets
etstandard2.0, .NET Framework, and modern .NET, so the property can be available on all targets while population is guarded for supported modern .NET targets.
Problem
.NET exposes HTTP response trailer fields through HttpResponseMessage.TrailingHeaders, but RestSharp currently maps only the regular response headers and content headers to RestResponse. The internal HttpResponseMessage is disposed after execution, so callers using the standard ExecuteAsync path cannot access trailer fields.
Trailer fields are useful for message integrity checks, signatures, delivery metrics, and post-processing status information. RFC 9110 also recommends storing them separately from the initial header section.
Proposed change
Compatibility
This would be an additive public API change. RestSharp targets
etstandard2.0, .NET Framework, and modern .NET, so the property can be available on all targets while population is guarded for supported modern .NET targets.