0

I've read about push-promise in HTTP/2 specs and several other tutorials, and have an idea as a concept.

I've read here in SO why bundling won't be as relevant in upcoming days. So, if I have to incorporate push promise into applications, where is the ideal place to do this. Should it be just before redirecting to the view from the Action method? Or, in the script in the view? As far as I've searched I couldn't find any examples.

Please someone share their experience implementing in the real code. Does it seem like an overhead if you have to support both the protocols?

Also, if I'm using IIS 10, then is there any configuration changes that I should do to support both protocols? [As far as I've read, we don't have to. But always better heed to some experts.]

Community
  • 1
  • 1
Manikandan Sigamani
  • 1,964
  • 1
  • 15
  • 28

1 Answers1

2

So, if I have to incorporate push promise into applications, where is the ideal place to do this. Should it be just before redirecting to the view from the Action method? Or, in the script in the view?

I did it in the controller action method while experimenting, but if you have common resources you may want to move it somewhere more fundamental/shared in the pipeline. Anywhere that has access to the HttpResponse object should work. As I noted here, you'll want to use the PushPromise overload that takes in an HTTP method and headers if what you're pushing will vary based on any request headers, e.g. accept-encoding (compression).

Does it seem like an overhead if you have to support both the protocols?

Also, if I'm using IIS 10, then is there any configuration changes that I should do to support both protocols?

You do not need to do anything explicitly to support both protocols; IIS will take care of it. Per David So of Microsoft, "provided the client and server configuration supports HTTP/2, then IIS will use HTTP/2 (or fallback to HTTP/1.1 if not possible)". This is true even if you're using server push: "If the underlying connection doesn’t support push (client disabled push, or HTTP/1.1 client), the call does nothing and returns success, so you can safely call the API without needing to worry about whether push is allowed."

Incidentally, if you want to disable HTTP/2 on Windows Server 2016, you can do so via the registry.

In addition to checking IIS logs, as David So suggested, you can verify HTTP/2 is being used by right-clicking on the headers row (Name, Status, Type, etc.) in Chrome's Network tab and checking off "Protocol"; you'll see "h2" for HTTP/2 responses. You can verify push promises are working by looking at the Chrome HTTP/2 internals page (chrome://net-internals/#http2) and looking at the "Pushed" and "Pushed and claimed" columns for your domain.

Community
  • 1
  • 1
ejohnson
  • 655
  • 7
  • 18
  • I believe you only want to use the overload with `headers` if the **contents** of the final file will vary based on the headers. in the case of compression the correct (desired) file would already be cached even if the user disabled compression and refreshed the page. only if the header affects the contents do you need to use this overload – Simon_Weaver Feb 23 '17 at 22:33
  • I'm not clear on your meaning. A push promise is for other resources that the client would request based on your initial response; I'm not sure what refreshing the page has to do with anything. Even if the initial request comes in with a compatible Accept-Encoding header, if you push resources using the [overload that takes only a virtual path](https://msdn.microsoft.com/en-us/library/dn823329.aspx), the pushed resources will be pushed uncompressed; you have to pass the initial request's (relevant) headers to the [other overload](https://msdn.microsoft.com/en-us/library/dn823340.aspx). – ejohnson Mar 01 '17 at 07:38