Add Api for HTTP/2 PushPromise

[aspnet-hello]

From @benaadams on Saturday, August 15, 2015 1:33:50 PM

Implement the PushPromise api as virtual NoOp in the abstract class HttpResponse.

Background

This API is to support applications sending push promises to HTTP 2.0 clients.

Current .NET v4.6 Api

public void PushPromise( string path )

public void PushPromise(
    string path,
    string method,
    NameValueCollection headers
)

Parameters
path Type: System.String
The URL of the push request. It should be the virtual path of the relative resource that the server wants to push to the client.

method Type: System.String
Http request method that would be used by the push request.

headers Type: System.Collections.Specialized.NameValueCollection
Http request header that would be used by the push request.

Suggested addition to Microsoft.AspNet.Http.Abstractions/HttpResponse.cs

Remarks
PushPromise is non-deterministic and applications shouldn't have logic that depends on it. Its only purpose is performance advantage in some cases. There are many conditions (protocol and implementation) that may cause to ignore the push requests completely. The expectation is based on fire-and-forget.

Rationale

Its out-of-band data like headers and cookies and is part of the response so should live at the HttpResponse level.

It is a core feature of http/2 rather than a extended addition that might be HttpContext related.

Its now standardised and implemented in all browsers - so is something I assume will be implemented in ASP.NET 5.

It already comes with two huge caveats:

• applications shouldn't have logic that depends on it
• There are many conditions (protocol and implementation) that may cause to ignore the push requests completely.

Which means it doesn't actually have to do anything at this time.

Suggested Api

public virtual void PushPromise(string path);
public virtual void PushPromise(string path, string method, IHeaderDictionary headers);

Copied from original issue: aspnet/HttpAbstractions#371

[aspnet-hello]

From @benaadams on Saturday, August 15, 2015 10:56:41 PM

Additional protocol activation background

• Currently use of http/2 in browsers requires https as none of them have implemented it over http.
• At one point the spec in draft also required ssl/tls; but due to pushback the final spec no longer requires it.
• There doesn't seem to be a huge appetite from browser vendors to implement http/2 over http
• When websockets was implemented there was a lot of trouble with proxies etc going over http; so to ensure maximum support, generally https has to be used.

In light of this it looks like http/2 is a defacto https only protocol; so PushPromise will only need to work over https and http/2 at this time.

[aspnet-hello]

From @muratg on Thursday, November 19, 2015 10:43:20 AM

As per previous discussion, we'll look into HTTP/2 after RTM.

[aspnet-hello]

From @Tratcher on Monday, November 28, 2016 12:08:22 PM

Related API questions:

• How do we surface to the app that this is an HTTP/2 request and that PushPromise will do something? HTTP/1.1 and HTTP/2 can be hosted on the same port (using TLS & ALPN).
• Do we also surface request priority and other new fields?

[aspnet-hello]

From @rh78 on Thursday, December 15, 2016 12:36:21 PM

Supporting this!!!

[aspnet-hello]

From @muratg on Wednesday, January 11, 2017 10:34:01 AM

Backlogging this one. cc @DamianEdwards

[codecadwallader]

Is there any update on HTTP/2 server push support for ASP.NET Core? Is it on a roadmap somewhere or ..?

[Tratcher]

@codecadwallader for which server? We're looking at HTTP/2 for Kestrel (https://github.com/aspnet/KestrelHttpServer/issues/73) for 2.2, but server push is pretty low on the priorty list there.

[codecadwallader]

@Tratcher thank you for the quick response and I've asked the same question over there. Particularly via Azure App Service.. so Kestrel with IIS as a reverse proxy in front.

[Tratcher]

The IIS+Kestrel reverse proxy scenario is one of the last we'd consider for end-to-end HTTP/2 and/or server push. The reverse proxy makes it an order of magnitude more complex. The new IIS In-Process server we're working on would be a more likely replacement here.

[codecadwallader]

Ok, thanks for the information. Do you know if the IIS In-Process server is the planned path forwards for Azure App Service?

[Tratcher]

Yes it is.

[shadialnamrouti]

Any update on the h2 PushPromise. I'd like to try this in .net core.

[trullock]

Has no progress really been made on this in ~2 years?

[Tratcher]

Closing as we've decided not to support push. See #4249 (comment) for details.