Runtime: Is there HTTP2 server push client support in .NET Core?

Created on 4 Jun 2019  路  10Comments  路  Source: dotnet/runtime

I can't find a way to receive server pushes using the HttpClient in .NET Core or Framework. I'm new to HTTP2 so I may just be missing something simple.

Here's my understanding from what documentation I can find:

  • Server push is available via HttpResponse.PushPromise in ASP.NET but not available in ASP.NET Core. I've spun up an ASP.NET web app and can see the server pushes in the Chrome developer tools. I can't accomplish the same in ASP.NET Core.
  • HTTP2 is supported in .NET Core's HTTPClient starting in .NET Core 3.0, but not in .NET Framework. I can perform a normal request/response using HTTP2 in .NET Core 3.0 preview 5 but not .NET Framework.
  • Receiving server pushes is not supported in .NET Core or Framework HttpClient.

I need to support HTTP2 from the client side, including server push, in both .NET Framework and .NET Core.

Can you comment on my assessment of .NET's HTTP2 support and point me to any resources you think will help?

area-System.Net.Http question

Most helpful comment

There are also emerging specs that use push promises to send unsolicited messages from the server to the client, such as RFC 8030 - Generic Event Delivery Using HTTP Push
which is designed to power the browser implementation of the Web Push API.

All 10 comments

@stephentoub

HTTP2 is supported in .NET Core's HTTPClient starting in .NET Core 3.0, but not in .NET Framework. I can perform a normal request/response using HTTP2 in .NET Core 3.0 but not .NET Framework.

Correct. Technically you could do HTTP/2 prior to 3.0 if you were on an OS that supported it and switched to using a handler that supported it, e.g. on a recent enough release of Windows and used WinHttpHandler.

Receiving server pushes is not supported in .NET Core or Framework HttpClient.

Correct.

Server push is available via HttpResponse.PushPromise in ASP.NET but not available in ASP.NET Core.

@anurse or @JamesNK can probably comment on this.

cc @Tratcher @halter73 @jkotalik

ASP.NET Core doesn't have support for push promises right now. https://github.com/aspnet/AspNetCore/issues/2727 is tracking this request for a future release.

This all sounds accurate. Note server push is designed for cache pre-populating which doesn't apply for HttpClient, there is no cache.

and can see the server pushes in the Chrome developer tools.

But is there an event anywhere that lets you directly accept that push?

Thanks. That answers my questions about current support.
Can you comment on any future plans to support server push in the client?

I realize that the HttpClient itself has no cache but what if I wanted to implement a cache or some other mechanism that needs access to the pushed data?

I can't speak to the schedule or priority, but I will outline some of the design challenges.

Push is architecturally problematic for HttpClient because the is based on a 1:1 request -> response model, you'd need some new event to surface unsolicited responses. Then there's a layering issue, where HttpClient is really broken up into HttpClient -> middleware -> handler. The event would have to be implemented at the low level handler and flow backwards up the stack. It would have to be a top level event on HttpMessageHandler and every middleware would need to implement it in order for it to flow well.

On top of that HttpMessageHandler is also used on some server APIs (see Asp.NET WebAPI). You'd want to ensure any new top level HttpMessageHandler push API also made sense there. The server side of the spec looks quite different (headers only, no body).

Thanks for the question, @vellozzi. I'm going to close this as answered, but feel free to re-open if there's something missed.

I also can't speak to the priority. My understanding is that it's fairly low, but is there really a need to have a special API to "surface unsolicited responses" in the client? Does such an API exist in the browser? I would think the pushed responses would just be surfaced if and when an associated request was made in the future. That could lead to question about how much to cache for how long, but would that necessarily mean new APIs aside from perhaps configuration.

Wanting to implement an HTTP cache as middleware would be a reasonable use case given that HttpClient doesn't have any caching.

There are also emerging specs that use push promises to send unsolicited messages from the server to the client, such as RFC 8030 - Generic Event Delivery Using HTTP Push
which is designed to power the browser implementation of the Web Push API.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

aggieben picture aggieben  路  3Comments

jamesqo picture jamesqo  路  3Comments

matty-hall picture matty-hall  路  3Comments

bencz picture bencz  路  3Comments

omariom picture omariom  路  3Comments