3.0 Preview 7: Can't get HTTP/2 trailer headers to appear

While Trailer headers appear to be supported (as should be the case with HTTP/2 over HTTPS), context.Response.SupportsTrailers() is true, the actual header after response body doesn’t appear to send. However, support is wonky enough across platforms I’m not 100% sure I trust the debugging tools either.

To Reproduce

1. Using 3.0 Preview 7 SDK
2. Grab this repo: MiniProfiler/dotnet
3. In Visual Studio, fire up samples\Samples.AspNetCore3
4. When making a request to https://localhost:5001, you’ll see a Trailer: Server-Timing header, but not the actual Server-Timing header that should be sent after the body.

Note: this requires the local HTTPS self-signed cert to work, dotnet dev-certs https if Kestrel won’t bind because it’ out of date.

Relevant code section is MiniProfilerMiddleware.cs line #93-96.

Expected behavior

A Server-Timing header is sent (so that app timings show up in browser tools)

Additional context

As said before - I don’t trust the debug tools here either, so after chatting with @anurse I’m filing to be sure. I don’t see the headers in Chrome, Firefox, or raw curl. There is no error anywhere and all code appears to be running, but it’s as if Kestrel isn’t flushing that header in some way…or I’m an idiot. I give it 10/90 odds on the split.

Thanks for the tip on HttpClient, I’ll try spinning up a client with it on latest preview tonight to see if it can see the headers. My understanding is at least Chrome should be working with the current code though.

cc @anurse @Tratcher @halter73 @jkotalik

[NickCraver]

Thanks for the tips all - I was able to test this tonight. Test harness:

using System;
using System.Net.Http;
using System.Threading.Tasks;

public class Program
{
    private static async Task Main(string[] args)
    {
        var url = args[0];
        Console.WriteLine("Fetching: " + url);
        using (var handler = new HttpClientHandler())
        {
            handler.ServerCertificateCustomValidationCallback = (_, __, ___, ____) => true;
            using (var client = new HttpClient(handler))
            {
                client.DefaultRequestVersion = new Version(2, 0);
                var message = await client.GetAsync(url);
                Console.WriteLine("ToString(): " + message);
                var body = await message.Content.ReadAsStringAsync();
                Console.WriteLine("Body Length: " + body.Length);
                Console.WriteLine("Trailing Headers: " + message.TrailingHeaders);
            }
        }
    }
}

And the result against the sample app:

λ dotnet run https://localhost:5001/
Fetching: https://localhost:5001/
ToString(): StatusCode: 200, ReasonPhrase: 'OK', Version: 2.0, Content: System.Net.Http.HttpConnectionResponseContent, Headers:
{
  Date: Wed, 31 Jul 2019 02:50:56 GMT
  Trailer: Server-Timing
  Server: Kestrel
  x-miniprofiler-ids: ["d100b23b-0a7a-4967-bbc7-3d18784a63fa","3b990764-dddb-4785-aa7a-f3b5e9d604cf"]
  Content-Type: text/html; charset=utf-8
}
Body Length: 5889
Trailing Headers: server-timing: total;desc="Total";dur=5.3

So…the issue is likely in Chrome somewhere not rendering these. Kestrel appears to be doing the right thing.

We can close this out to cleanup. I appreciate the debugging tips, that helps a lot tracking things down.

[JamesNK]

Instead of disabling TLS to view the HTTP/2 frames in Wireshark, you can follow the “Using the (Pre)-Master-Secret” of this Wireshark doc to decrypt the browser session.

When I setup Wireshark I tried for hours to read TLS but couldn’t get it to work 😢