24

每个人，就我而言，这个问题在 EDIT 2 中得到了解决。虽然这只是问题的 IIS 方面的部分解决方案，但它正是我所寻找的。

因此，我将把我的查询添加到有关该主题的大量问题中。

我正在尝试对来自 WCF 服务的大型肥皂响应启用 GZip 压缩。到目前为止，我已按照此处和其他各种地方的说明在 IIS 上启用动态压缩。这是我在 applicationHost.config 中的 dynamicTypes 部分：

<dynamicTypes>
    <add mimeType="text/*" enabled="true" />
    <add mimeType="message/*" enabled="true" />
    <add mimeType="application/x-javascript" enabled="true" />
    <add mimeType="application/atom+xml" enabled="true" />
    <add mimeType="application/xaml+xml" enabled="true" />
    <add mimeType="application/xop+xml" enabled="true" />
    <add mimeType="application/soap+xml" enabled="true" />
    <add mimeType="*/*" enabled="false" />
</dynamicTypes>

并且：

<urlCompression doDynamicCompression="true" doStaticCompression="true" />

虽然我不太清楚为什么需要这样做。

以防万一，在其中添加了一些额外的 mime 类型。我已经实现了 IClientMessageInspector 来添加 Accept-Encoding: gzip, deflate 到我客户的 HttpRequests。这是取自 fiddler 的请求标头示例：

POST http://[omitted]/TestMtomService/TextService.svc HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Accept-Encoding: gzip, deflate
Host: [omitted]
Content-Length: 542
Expect: 100-continue

现在，这行不通。无论消息大小如何（尝试最大为 1.5Mb），都不会发生压缩。我看过这篇文章，但没有遇到他描述的异常，所以我没有尝试过他提出的 CodeProject 实现。此外，我还看到了很多其他的实现，它们应该可以让它工作，但无法理解它们（例如，msdn 的 GZip 编码器）。为什么我需要实现编码器或代码项目解决方案？IIS 不应该负责压缩吗？

那么我还需要做什么才能使其正常工作？

乔尼

编辑：我认为 WCF 绑定可能值得发布，但我不确定它们是否相关（这些来自客户端）：

<system.serviceModel>
<bindings>
    <wsHttpBinding>
    <binding name="WsTextBinding" closeTimeout="00:01:00" openTimeout="00:01:00"
      receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false"
      transactionFlow="false" hostNameComparisonMode="StrongWildcard"
      maxBufferPoolSize="5000000" maxReceivedMessageSize="5000000"
      messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
      allowCookies="false">
      <readerQuotas maxDepth="32" maxStringContentLength="5000000"
        maxArrayLength="5000000" maxBytesPerRead="5000000" maxNameTableCharCount="5000000" />
      <reliableSession ordered="true" inactivityTimeout="00:10:00"
        enabled="false" />
      <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None" realm=""/>
        <message clientCredentialType="None" negotiateServiceCredential="false"
          algorithmSuite="Default" establishSecurityContext="false" />
      </security>
<client>
  <endpoint address="http://[omitted]/TestMtomService/TextService.svc"
   binding="wsHttpBinding" bindingConfiguration="WsTextBinding" behaviorConfiguration="GzipCompressionBehavior"
   contract="TestMtomModel.ICustomerService" name="WsTextEndpoint">
  </endpoint>
</client>
<behaviors>
  <endpointBehaviors>
    <behavior name="GzipCompressionBehavior">
      <gzipCompression />
    </behavior>
  </endpointBehaviors>
</behaviors>
<extensions>
  <behaviorExtensions>
    <add name="gzipCompression"
         type="TestMtomModel.Behavior.GzipCompressionBehaviorExtensionElement, TestMtomModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  </behaviorExtensions>
</extensions>
    </binding>
  </wsHttpBinding>
</bindings>

编辑2：对于处于这种神秘情况的其他人，我有一个部分解决方案。即，我已经让 IIS7 至少压缩了来自服务的肥皂消息（尽管我现在在客户端上遇到了一个异常，但是已经发布了几个解决方案）。问题是我的服务器上没有安装 DynamicCompressionModule。对我来说，“安装”它实际上意味着只需将这一行添加到 applicationHost.config 的部分：

<add name="DynamicCompressionModule" image="%windir%\System32\inetsrv\compdyn.dll" />

（假设 dll 存在于该目录中，在我的情况下它确实存在。）然后通过 IIS7 的 Modules 部分为网站或服务器添加模块。

4

8 回答 8

14

尝试添加 'application/soap+xml; charset=utf-8' 作为 applicationHost 中的动态类型。添加这个字符集部分帮助我为来自我的 http 处理程序的一些 JSON 响应启用压缩。

于 2010-06-16T05:34:15.663 回答
10

这与@marko 的答案基本相同 - 有详细的步骤。每次我重新审视它时，这都是一个令人沮丧的话题，所以我想概述一下我需要做的一切才能让它发挥作用。

  • 首先，您需要在 IIS7 上使用 .NET 4。这是因为直到 .NET 4，WCF 才能够自动解压缩 gzip 流。' Whats new in WCF 4 '中描述了这方面的细节（反馈中的一些有用的评论）。

    通过允许客户端自动协商使用 gzip 或 deflate 压缩流，然后自动解压缩它们，我们在使用 HTTP 时使这变得更容易。

  • 其次，确保您在 IIS 中启用了动态压缩模块。您可能需要转到“程序和功能”来安装它。确保您已为相关 Web 应用程序启用它 - 因为它不是全局设置。

  • 现在 WPF 使用 MIME 类型application/soap+xml; charset=utf-8进行 HTTP 传输（至少使用 wsHttpBinding 是这样）。默认情况下，这不是动态类型，因此需要将其添加到applicationHost.config文件中。

    只需在服务器上编辑此文件：C:\Windows\System32\Inetsrv\Config\applicationHost.config

    在<dynamicTypes>节点中添加以下行（BEFORE THE / LINE）：

    <add mimeType="application/soap+xml; charset=utf-8" enabled="true" />

    有关 applicationHost.config 文件的更多信息

  • 重新启动 IIS

您现在应该有压缩数据 - 可以在Fiddler 中进行验证。

于 2010-09-14T03:29:12.343 回答
1

我也一直在努力解决这个问题，并且无法让它与我的 .svc 一起使用，即使在同一个应用程序中使用 .aspx 文件也很好。事实证明，它只适用于basicHttpBinding而不是wsHttpBinding或二进制编码的customBinding。这对我来说很好，因为压缩因子超过了二进制编码器的好处（它将消息大小减少了很多，但不是压缩给出的 10 倍）。

于 2011-03-02T13:28:31.087 回答
0

mime 类型最有可能Application/octet-stream

于 2011-08-26T12:20:11.933 回答
0

最好的办法是评估您遇到问题的特定 mime 类型（例如 Fiddler），并确保将其合并到 applicationHost.config 中。如果压缩已正确安装和配置，失败的请求跟踪将让您知道压缩不是使用“NO_MATCHING_CONTENT_TYPE”处置执行的。

于 2010-06-16T17:15:25.677 回答
0

只是为了其他可能在未来寻找的人。我们升级到 Windows 2012 服务器和 IIS 8。适用于 IIS 7 的旧配置压缩 mimetype 不适用于 IIS 8。

所以，我在这里尝试了几个建议，但没有任何效果。我最终只是将它添加到 httpcompression dynamictypes:multipart/*然后 gzip 压缩再次起作用。

希望这对其他人有帮助。

于 2015-02-19T21:54:41.217 回答
0

如果有人在以 WebApp 形式在 Azure 中托管时偶然发现此问题，您可以使用名为“IIS 管理器”的扩展名配置 applicationHost.config，并使用“扩展”下的 azure 门户。有关扩展程序本身的更多信息https://github.com/shibyan/IISManager

于 2017-10-05T09:30:58.390 回答
0

很多人都在为 WCF 服务启用 IIS 级压缩而苦苦挣扎。主要是人们在 wsHttpBinding 上苦苦挣扎，如果在 IIS 中启用了动态压缩，basicHttpBinding 就会开箱即用地进行压缩。我不打算讨论如何启用动态压缩，因为它在许多不同的帖子中都有介绍，只需搜索“iis compression application/soap+xml”即可。如前所述，如果您已正确配置所有内容，您应该能够看到使用Content-Encoding 压缩的 WCF 响应：gzip在响应头中。我建议使用 Fiddler 来跟踪您的请求/响应。这是我（任何其他人）使用 basicHttpBinding 的经验。那么问题就变成了为什么它不能与 wsHttpBinding 一起使用？毫无疑问，您已经读过这是因为这两个绑定之间的Content-Type不同。basicHttpBinding 使用Content-Type: text/xml; charset=utf-8其中 wsHttpBinding 使用Content-Type: application/soap+xml; 字符集=utf-8. 前者包含在 dynamicTypes 下的默认 IIS applicationHost.config 设置中。后者不是。您可能读到需要添加这个额外的 mimeType 并重新启动 IIS 来解决这个问题。这对某些人有效，但对许多人无效。有些人宣称它与 wsHttpBinding 根本不兼容。这是问题所在。可能有两个applicationHost.config 文件：

C:\Windows\System32\inetsrv\config
C:\Windows\SysWOW64\inetsrv\Config

System32 是 64 位的，是您安装 IIS 时使用的。这也是您为添加额外的 mimeType 而修改的，或者您认为的！

无法手动编辑 applicationhost.config - 必须阅读

事实证明，如果您使用 Notepad++ 等 32 位应用程序，您最终修改的是 SysWOW64 文件夹中的文件。这对你来说是完全透明的。如果您使用常规记事本应用程序，您会注意到您添加的 mimeType 实际上不在位于 System32 文件夹中的文件中，它被神奇地添加到 SysWOW64 文件夹中，即使您从未真正浏览过它文件夹开始。希望这可以为您节省许多小时的悲伤。

于 2015-09-16T14:57:35.330 回答