MVC 应用程序中 HttpResponse.PushPromise() 的工作示例答案

【问题标题】：An working example of HttpResponse.PushPromise() in MVC ApplicationsMVC 应用程序中 HttpResponse.PushPromise() 的工作示例
【发布时间】：2016-05-15 03:18:38
【问题描述】：

我已经阅读了 HTTP/2 规范和其他几个教程中关于 push-promise 的内容，并且有了一个概念。

我已阅读 here in SO 为什么捆绑在未来几天不再那么重要。因此，如果我必须将 push promise 合并到应用程序中，那么理想的地方是哪里。是否应该在从 Action 方法重定向到视图之前？或者，在视图中的脚本中？据我搜索，我找不到任何示例。

请有人分享他们在真实代码中实现的经验。如果您必须同时支持这两种协议，这似乎是一种开销吗？

另外，如果我使用的是 IIS 10，那么我是否应该进行任何配置更改以支持这两种协议？ [据我所知，我们不必这样做。但总是更好地听取一些专家的意见。]

【问题讨论】：

标签： asp.net-mvc http2 .net-4.6 push-promise

【解决方案1】：

所以，如果我必须将 push promise 合并到应用程序中，那么理想的地方是哪里。是否应该在从 Action 方法重定向到视图之前？或者，在视图中的脚本中？

我在实验时在控制器操作方法中进行了此操作，但如果您有公共资源，您可能希望将其移动到管道中更基本/共享的位置。可以访问HttpResponse 对象的任何地方都应该可以工作。正如我提到的here，如果您推送的内容会因任何请求标头而异，例如接受编码（压缩）。

如果您必须同时支持这两种协议，这似乎是一种开销吗？

另外，如果我使用的是 IIS 10，那么我是否应该进行任何配置更改以支持这两种协议？

您不需要明确地做任何事情来支持这两种协议； IIS 会处理它。根据David So of Microsoft，“如果客户端和服务器配置支持 HTTP/2，那么 IIS 将使用 HTTP/2（如果不可能，则回退到 HTTP/1.1）”。即使您使用服务器推送也是如此：“如果底层连接不支持推送（客户端禁用推送，或 HTTP/1.1 客户端），则调用不执行任何操作并返回成功，因此您可以安全地调用 API 而无需需要担心是否允许推送。”

顺便说一句，如果你想在 Windows Server 2016 上禁用 HTTP/2，你可以这样做via the registry。

除了检查 IIS 日志，正如 David So 所建议的那样，您可以通过右键单击 Chrome 网络选项卡中的标题行（名称、状态、类型等）并选中“协议”;您将看到 HTTP/2 响应的“h2”。您可以通过查看 Chrome HTTP/2 内部页面 (chrome://net-internals/#http2) 并查看您的域的“已推送”和“已推送并声明”列来验证推送承诺是否有效。

【讨论】：

如果最终文件的 contents 会因标题而异，我相信您只想使用 headers 的重载。在压缩的情况下，即使用户禁用压缩并刷新页面，正确的（所需）文件也已经被缓存。仅当标题影响内容时才需要使用此重载
我不清楚你的意思。推送承诺是针对客户端根据您的初始响应请求的其他资源；我不确定刷新页面与任何事情有什么关系。即使初始请求带有兼容的 Accept-Encoding 标头，如果您使用 overload that takes only a virtual path 推送资源，推送的资源将被未压缩推送；您必须将初始请求的（相关）标头传递给other overload。