我已经阅读了关于HTTP / 2规范和其他几个教程的推送承诺，并且有一个想法作为一个概念。
我已经阅读here in SO为什么捆绑在未来几天不会那么重要。因此，如果我必须将推送承诺合并到应用程序中，那么这是执行此操作的理想位置。它应该在从Action方法重定向到视图之前吗？或者，在视图中的脚本中？据我搜索，我找不到任何例子。
请有人分享他们在实际代码中实施的经验。如果你必须支持这两种协议，它看起来像是一种开销吗？
此外，如果我使用的是IIS 10，那么我是否应该进行任何配置更改以支持这两种协议？ [据我所知，我们没有。但总是更好地留意一些专家。]
答案 0 :(得分：2)
因此，如果我必须将推送承诺合并到应用程序中，那么这是执行此操作的理想位置。它应该在从Action方法重定向到视图之前吗？或者，在视图的脚本中？
我在试验时在控制器动作方法中做到了，但是如果你有共同的资源，你可能想把它移动到管道中更基本/共享的地方。有权访问HttpResponse对象的任何地方都应该有效。正如我所提到的here，如果您推送的内容因任何请求而异，您会想要使用带有HTTP方法和标题的PushPromise overload标题，例如接受编码（压缩）。
如果你必须同时支持这两种协议，它看起来像是一种开销吗？
此外，如果我使用IIS 10，那么我是否应该对配置进行任何配置更改以支持这两种协议？
您无需明确执行任何操作即可支持这两种协议; IIS将负责处理它。每David So of Microsoft，＆＃34;如果客户端和服务器配置支持HTTP / 2，则IIS将使用HTTP / 2（如果不可能则回退到HTTP / 1.1）＆＃34;。即使您正在使用服务器推送也是如此：＆＃34;如果底层连接不支持推送（客户端禁用推送或HTTP / 1.1客户端），则调用不执行任何操作并返回成功，因此您可以安全地调用API而不必担心是否允许推送。＆＃34;
顺便提一下，如果要在Windows Server 2016上禁用HTTP / 2，可以via the registry执行此操作。
除了检查IIS日志之外，正如David So建议的那样，您可以通过右键单击Chrome网络标签中的标题行（名称，状态，类型等）来验证是否正在使用HTTP / 2并检查＆＃34;协议＆＃34 ;;你会看到＆＃34; h2＆＃34;用于HTTP / 2响应。您可以通过查看Chrome HTTP / 2内部页面（chrome：// net-internals /＃http2）并查看＆＃34; Pushed＆＃34;来验证推送承诺是否有效。并且＆＃34;推动并宣称＆＃34;您所在域的列。