【问题标题】:maxReceivedMessageSize not fixing 413: Request Entity Too LargemaxReceivedMessageSize 未修复 413:请求实体太大
【发布时间】:2013-01-16 04:21:24
【问题描述】:

我对 WCF Web 服务的调用失败并显示 System.Net.WebException: The request failed with HTTP status 413: Request Entity Too Large.

检查 Fiddler,我看到我正在发送:

内容长度:149839

超过 65KB。

在服务器上启用 WCF 跟踪,我看到了:

System.ServiceModel.ProtocolException:最大消息大小配额 已超出传入消息 (65536)。为了增加 配额,在适当的地方使用 MaxReceivedMessageSize 属性 绑定元素。

添加此属性并不能解决问题。

我只尝试了该属性,并且(后来)尝试了帖子建议的其他各种属性。这是我目前拥有的(在服务器上)

<basicHttpBinding>

  <binding name="PricerServiceSoap"
    closeTimeout="00:10:00" openTimeout="00:10:00"
    receiveTimeout="00:10:00" sendTimeout="00:10:00"
    maxBufferSize="2147483647"    
    maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">

    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
      maxArrayLength="2147483647" maxBytesPerRead="2147483647"
      maxNameTableCharCount="2147483647" />
  </binding>

</basicHttpBinding>

我的唯一端点(&lt;client&gt; 下)是:

<endpoint address="/NetPricingService/Service.asmx"
  binding="basicHttpBinding" bindingConfiguration="PricerServiceSoap"
  contract="Pricing.PricerService.PricerServiceSoap"
  name="PricerServiceSoap" />

我还添加了:

<dataContractSerializer maxItemsInObjectGraph="2147483647"/>

&lt;behavior&gt;下。

我什至运行过(对于 IIS 7):

%windir%\system32\inetsrv\appcmd set config "WebServicesDev/PricingService"
-section:requestFiltering -requestLimits.maxAllowedContentLength:104857600
-commitpath:apphost

没什么区别。

一个问题是这是一个 WCF 服务,旨在替换旧的 ASMX 服务。服务框架是使用现有 WSDL 中的 svcutil 生成的。我无法更改客户端配置(并且客户端使用多种语言)。我的测试客户端项目使用添加 Web 引用(在Add Service Reference / Advanced 下)导入了服务,所以我没有 WCF 配置。但是,如果我将其指向较旧的 ASMX 服务,则测试客户端可以正常工作。

如何解决或诊断此问题?

其他信息

如果我使用 Microsoft 服务配置编辑器生成配置(设置 maxReceivedMessageSize 和 maxBufferSize),它可以工作。问题是端点随后在&lt;service&gt; 下指定,它不会让我指定/NetPricingService/Service.asmx 相对地址。如果我在 svcutil 生成的配置中编辑绑定(端点位于 &lt;client&gt; 下),它不适用于大型请求。

【问题讨论】:

    标签: wcf iis .net-4.0 web-config wcf-binding


    【解决方案1】:

    答案是盯着我的脸。

    svcutil 生成的配置是针对客户端的。我在服务器上使用它。

    我正在编辑&lt;client&gt; 下指定的端点的绑定,这对服务完全没有影响。

    添加适当的&lt;service&gt; 端点并在其绑定上设置 maxReceivedMessageSize 和 maxBufferSize 解决了该问题。

    【讨论】:

    • 要为 TrueWill 的回答添加细节:您需要将 标签添加到托管 Web 服务的 web.config,而不是更改服务所在的 web.config 中的 标签边界。在 标记中,通过 bindingconfiguration 添加对新绑定的引用。在 bindings 节点下创建新的绑定,并在那里添加 maxBufferPoolSize 和 maxReceivedMessageSize 设置。
    • 谢谢。我可能一整天都没有注意到它。
    • 这终于让我找到了解决方案。 &lt;services&gt; 部分是“不需要”的“简单”.NET4 配置没有使用我的 httpBinding .. 使用绑定显式添加服务解决了问题。
    【解决方案2】:

    我遇到了类似的问题。 对我来说,问题是我的端点没有使用 bindingConfiguration 明确命名绑定,因此一定是在某处使用了一些默认值。

    我有:

    <webHttpBinding>
        <binding 
            name="myXmlHttpBinding" 
            maxReceivedMessageSize="10485760" 
            maxBufferSize="10485760">
            <readerQuotas 
                maxDepth="2147483647" 
                maxStringContentLength="2147483647" 
                maxArrayLength="2147483647" 
                maxBytesPerRead="2147483647" 
                maxNameTableCharCount="2147483647"/>
            <security mode="None"/>
        </binding>
    </webHttpBinding>
    

    我的端点定义为:

    <service 
        name="blah.SomeService">
        <endpoint 
            address="" 
            behaviorConfiguration="WebHttpBehavior" 
            binding="webHttpBinding" 
            contract="blah.ISomeService">
    
            <identity>
                <dns value="localhost"/>
            </identity>
        </endpoint>
    </service>
    

    一旦我将端点更改为:

      <service name="blah.SomeService">
        <endpoint address="" 
            behaviorConfiguration="WebHttpBehavior" 
            binding="webHttpBinding" 
            bindingConfiguration="myXmlHttpBinding" 
            contract="blah.ISomeService">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
      </service>
    

    【讨论】:

      【解决方案3】:

      我也遇到了这个问题,并在 fiddler 中意识到正在工作的最大 Content-Length 最终为 30000000。

      在验证我的 WCF 配置正确后,我发现一篇文章建议修改 IIS 设置,请求过滤。

      Large file upload failure for Web application calling WCF service – 413 Request entity too large

      1. 打开 IIS 管理器
      2. 选择您的应用程序
      3. 选择请求过滤图标。
      4. 选择编辑功能设置...(右侧面板)
      5. 调整最大允许内容长度(字节)默认显示为 30000000

      或 web.config 文件示例

      <system.webServer>
        <security>
          <requestFiltering>
            <requestLimits maxAllowedContentLength="50000000" />
          </requestFiltering>
        </security>
      </system.webServer>
      

      【讨论】:

      • 这适用于在 asp.net MVC 5 上上传文件。非常感谢。
      【解决方案4】:

      尝试了 10 个不同博客的内容,我的同事发现了。 除了 basicHttpBinding 部分之外,我们还必须在其中添加一个 basicHttpsBinding 部分。我们有一个调用 wcf 的 webapi 服务。 webapi 方法在调用 wcf 服务方法时捕获了实体太大错误。此更改已应用到 wcf 服务的 web.config 文件中。

      【讨论】:

        【解决方案5】:

        没有任何建议对我有用。解决问题的方法是在System.ServiceModel.Channels.HttpTransportBindingElement 中增加MaxReceivedMessageSize

        有两个不同的MaxReceivedMessageSize参数:

        • MaxReceivedMessageSize 在 System.ServiceModel.Configuration.BasicHttpBindingElement
        • MaxReceivedMessageSize 在 System.ServiceModel.Channels.HttpTransportBindingElement

        在转储文件中,我看到它因为HttpTransportBindingElement中的限制而失败

        将此添加到我的 web.config 解决了这个问题:

        <customBinding>
           <binding closeTimeout="00:10:00" openTimeout="00:10:00" sendTimeout="00:10:00">
              <httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" useDefaultWebProxy="true" transferMode="Buffered" />
           </binding>
        </customBinding>
        

        来源:WCF service shows 413 Request Entity Too Large error when uploading files over 64 KB

        【讨论】:

        • 谢谢 - 顺便说一句,链接已损坏。
        【解决方案6】:

        添加这个为我解决它:

            <bindings>
                <basicHttpBinding>
                    <binding name="BasicHttpBinding_Example"
         maxBufferSize="2147483647" 
        maxReceivedMessageSize="2147483647">
                    </binding>
                </basicHttpBinding>
            </bindings>
        

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2014-12-30
          • 2014-12-23
          • 2018-08-20
          • 2012-09-23
          • 2015-10-04
          • 2015-01-25
          • 2014-12-04
          相关资源
          最近更新 更多