【问题标题】:WCF Service Error 413 Entity Too LargeWCF 服务错误 413 实体太大
【发布时间】:2014-01-06 05:24:09
【问题描述】:

需要进一步了解与 WCF 错误相关的信息,即请求实体太大(错误 413)。

差不多,服务是一个简单的 [OperationContract],接受一个字符串作为参数。

<IService.cs>
[OperationContract]
string UploadReportText(string ReportText);


<Service.cs>
public string UploadReportText(string ReportText)
{
  // Code to process data passed.
}

我已经为该服务设置了 Web 配置,如下所示:

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

虽然我认为 IIS 中的 uploadReadAhead 值不需要被触及(因为我没有使用 SSL),但我仍然将其修改为 2147483647。

在 Chrome 中跟踪调用该服务的应用之一,我可以看到数据 Content-Length 为 169786。

真的很难找到与此相关的更进一步的地方。

欣赏任何见解。谢谢

更新: 附加信息 如果我将传递给服务的字符串数据设置为更小的长度,我不会收到错误消息。我所做的与此相关的大部分搜索都指向 maxReceivedMessageSize 需要调整为最大可能值,但在 web config 中设置它似乎没有效果。

更新: 启用日志记录,我收到此消息:

异常详情:System.ServiceModel.ProtocolException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

【问题讨论】:

    标签: wcf


    【解决方案1】:

    对我来说,我只需要将这个块添加到我的 web.config

    <bindings>
      <webHttpBinding>
        <binding maxReceivedMessageSize="2147483647"
                 maxBufferPoolSize="2147483647777" >
          <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
                        maxArrayLength="2147483647" maxBytesPerRead="2147483647"
                        maxNameTableCharCount="2147483647" />
        </binding>
      </webHttpBinding>
    </bindings>
    

    我的 web.config 已经在使用webHttpBinding 绑定(如下所示),它只需要这个&lt;bindings&gt; 部分来允许它上传大文件。

    <services>
        <service name="PocketCRMServices.Service1">
          <endpoint address="../Service1.svc"
            binding="webHttpBinding"
            contract="PocketCRMServices.IService1"
            behaviorConfiguration="webBehaviour" />
        </service>
    </services>
    

    【讨论】:

      【解决方案2】:

      正如 Vignesh 所说,您没有为定义的绑定分配名称。这使它成为该绑定的默认配置(在 WCF 4.0+ 之后的版本中),因此您实际上有两个选择。根据 Vignesh 的建议,您可以为其命名、创建显式端点并通过 bindingCongifuration 引用它。

      或者,您可以使用&lt;system.serviceModel&gt; 部分的&lt;proctolMapping&gt; 部分将webHttpBinding 指定为http 的默认绑定(http 的正常WCF 默认绑定是basicHttpBinding

      <system.serviceModel>
        <protocolMapping>
          <add binding="webHttpBinding" scheme="http" />
        </protocoalMapping>
      </system.serviceModel>
      

      这在您的服务的配置文件中。

      【讨论】:

        【解决方案3】:

        还需要在您的客户端做同样的事情。您的客户端配置(app.config 是否还包括大消息大小的绑定配置。

        【讨论】:

        • 为了简单和一致,是的。但是,如果客户端没有收到较大的响应,那么从技术上讲,不需要设置较大的值。
        【解决方案4】:

        首先:在您的服务器端,您定义具有较大消息大小的绑定配置,但您不从端点引用它。

          <service behaviorConfiguration="WCFReferrals.Service1Behavior"
                     name="WCFReferrals.Referrals">
               <endpoint 
                     address="" 
                     binding="wsHttpBinding" 
                     bindingConfiguration="LargeSizeMessages"  <== you need to reference the binding config (by specifying its name
                    contract="WCFReferrals.IReferrals">
                </endpoint>
                .....
              </service>
              ....
              <binding name="LargeSizeMessages"   <== give it a meaningful name
                   maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
                   <readerQuotas maxDepth="32" maxStringContentLength="2147483647"
                       maxArrayLength="2147483647" maxBytesPerRead="4096" 
                       maxNameTableCharCount="16384" />
              </binding>
        

        Source

        Refer this too

        【讨论】:

        • binding configuration= "LargeSizeMessages" 在尝试了许多解决方案后成功了
        猜你喜欢
        • 2015-10-18
        • 2014-01-19
        • 2016-06-10
        • 1970-01-01
        • 2012-11-14
        • 2015-05-03
        • 1970-01-01
        • 2021-10-08
        • 1970-01-01
        相关资源
        最近更新 更多