（413）リクエストエンティティが大きすぎます| uploadReadAheadSize

.NET 4.0でWCFサービスを作成しました。これはx64、IIS 7.5を搭載したWindows 7 Ultimateシステムでホストされています。サービスメソッドの1つに引数として「オブジェクト」があり、画像を含むbyte []を送信しようとしています。この画像のファイルサイズが約未満の場合。48KB、すべてうまくいきます。しかし、より大きな画像をアップロードしようとすると、WCFサービスがエラーを返し(413) Request Entity Too Large. ます。当然のことながら、3時間を費やしてエラーメッセージをグーグル検索しました。だから私がやったことは次のコマンドを使用することです（10485760 = 10MB）：

"appcmd.exe set config -section:system.webserver/serverruntime/uploadreadaheadsize: 10485760 /commit:apphost"

"cscript adsutil.vbs set w3svc/<APP_ID>/uploadreadaheadsize 10485760"

IISマネージャーを使用して、サイトを開き、[管理]の[構成エディター]に移動して値を設定しました。残念ながら、まだRequest Entity Too Largeエラーが発生し、本当にイライラしています！

それで、誰かがこのエラーを修正するために他に何ができるか知っていますか？

これはIISの問題ではなく、WCFの問題です。WCFはデフォルトでメッセージを65KBに制限して、大きなメッセージによるサービス拒否攻撃を回避しています。また、MTOMを使用しない場合は、byte []をbase64エンコードされた文字列に送信します（サイズが33％増加）=> 48KB * 1,33 = 64KB

この問題を解決するには、より大きなメッセージを受け入れるようにサービスを再構成する必要があります。この問題は、以前は400 Bad Requestエラーを引き起こしていましたが、新しいバージョンでは、WCFはこのタイプのエラーの正しいステータスコードである413の使用を開始しました。

maxReceivedMessageSizeバインディングを設定する必要があります。を設定する必要がある場合もありreaderQuotasます。

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding maxReceivedMessageSize="10485760">
        <readerQuotas ... />
      </binding>
    </basicHttpBinding>
  </bindings>  
</system.serviceModel>

WCF RESTサービスを使用するIIS 7.5でも同じ問題が発生していました。65Kを超えるファイルをPOST経由でアップロードしようとすると、エラー413「リクエストエンティティが大きすぎます」が返されます。

最初に理解する必要があるのは、web.configで構成したバインディングの種類です。ここに素晴らしい記事があります...

BasicHttpBinding対WsHttpBinding対WebHttpBinding

RESTサービスがある場合は、「webHttpBinding」として構成する必要があります。ここに修正があります：

<system.serviceModel>

<bindings>
   <webHttpBinding>
    <binding 
      maxBufferPoolSize="2147483647" 
      maxReceivedMessageSize="2147483647" 
      maxBufferSize="2147483647" transferMode="Streamed">
    </binding>  
   </webHttpBinding>
</bindings>

私は同じ問題を抱えており、uploadReadAheadSize解決した問題を設定しました：

http://www.iis.net/configreference/system.webserver/serverruntime

「値は0から2147483647の間でなければなりません。」

cmd-thingを実行したくない場合は、applicationHost.config-fleで簡単に設定できます。

その中にあります WindowsFOLDER\System32\inetsrv\config（2008サーバー）。

メモ帳で開く必要があります。最初にファイルのバックアップを行ってください。

configのコメントによると、セクションのロックを解除するための推奨される方法は、場所タグを使用することです：

<location path="Default Web Site" overrideMode="Allow">
    <system.webServer>
        <asp />
    </system.webServer>
</location>"

したがって、下部に書き込むことができます（以前は存在しなかったため）。maxvalueここに書きます-必要に応じて独自の値を書きます。

<location path="THENAMEOFTHESITEYOUHAVE" overrideMode="Allow">
    <system.webServer>
        <asp />
        <serverRuntime uploadReadAheadSize="2147483647" />
    </system.webServer>
</location>

</configuration>たとえば、それを前に最後に置くと、どこにあるかがわかります。

あなたの問題が解決することを願っています。これはSSLオーバーヘッドの問題でした。ポストが多すぎるとアプリケーションがフリーズし、（413）Request Entity Too Largeエラーが発生しました。

maxWCFサービス構成ファイルのバインド内で設定を行っていても、次のエラーメッセージが表示されました。

<basicHttpBinding>
        <binding name="NewBinding1"
                 receiveTimeout="01:00:00"
                 sendTimeout="01:00:00"
                 maxBufferSize="2000000000"
                 maxReceivedMessageSize="2000000000">

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

これらのバインディング設定が適用されていないように見えたため、次のエラーメッセージが表示されました。

IIS7-（413）サービスへの接続時にエンティティが大きすぎます。

。

問題

name=""の<service>タグ内の属性は、思っていたようにフリーテキストフィールドでweb.configはないことに気付きました。これは、このドキュメントページで説明されているサービスコントラクトの実装の完全修飾名です。

それが一致しない場合、バインディング設定は適用されません！

<services>
  <!-- The namespace appears in the 'name' attribute -->
  <service name="Your.Namespace.ConcreteClassName">
    <endpoint address="http://localhost/YourService.svc"
      binding="basicHttpBinding" bindingConfiguration="NewBinding1"
      contract="Your.Namespace.IConcreteClassName" />
  </service>
</services>

それが誰かの痛みを救うことを願っています...

このスレッドのすべての解決策を試してもこの問題が発生し、SSL（httpsなど）を介してサービスに接続している場合、これが役立つ可能性があります。

http://forums.newatlanta.com/messages.cfm?threadid=554611A2-E03F-43DB-92F996F4B6222BC0&#top

要約すると（リンクが将来停止する場合）、要求が十分に大きい場合、クライアントとサービス間の証明書ネゴシエーションはランダムに失敗します。これが起こらないようにするには、SSLバインディングで特定の設定を有効にする必要があります。IISサーバーから、次の手順を実行する必要があります。

1. cmdまたはpowershellを使用して、を実行しnetsh http show sslcertます。これにより、現在の構成が得られます。これを何らかの方法で保存して、後で再び参照できるようにします。
2. 「クライアント証明書のネゴシエート」が無効になっていることに注意してください。これは問題の設定です。次の手順では、これを有効にする方法を示します。
3. 残念ながら、既存のバインディングを変更する方法はありません。それを削除して、再度追加する必要があります。netsh http delete sslcert <ipaddress>:<port>どこで実行する<ipaddress>:<port>以前に保存した構成に示すポート：IPです。
4. これで、バインディングを再度追加できます。netsh http add sslcert ここ（MSDN）の有効なパラメーターを表示できますが、ほとんどの場合、コマンドは次のようになります。

netsh http add sslcert ipport=<ipaddress>:<port> appid=<application ID from saved config including the {}> certhash=<certificate hash from saved config> certstorename=<certificate store name from saved config> clientcertnegotiation=enable

複数のSSLバインディングがある場合は、それぞれに対してプロセスを繰り返します。うまくいけば、これがこの問題が引き起こした何時間もの頭痛の時間を他の誰かに救うのに役立つことを願っています。

編集：私の経験では、実際netsh http add sslcertにコマンドラインから直接コマンドを実行することはできません。最初にnetshプロンプトを入力して入力し、それを機能させるには次のnetshようhttp add sslcert ipport=...にコマンドを発行する必要があります。

これは私が問題を解決するのに役立ちました（1行-読みやすさ/コピー可能性のために分割）：

C:\Windows\System32\inetsrv\appcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost

私にとってはuploadReadAheadSize、WCFバインディングの制限を増やした後で、intをMaxValue に設定することで問題も修正されました。

SSLを使用すると、リクエストエンティティボディ全体がプリロードされ、このメタベースプロパティが使用されるようです。

詳細については、以下を参照してください。

リクエストエンティティが大きすぎるため、ページは表示されませんでした。iis7

IIS WCFエラー413：エンティティへのリクエストを大きくして、SharepointでWCFサービスを使用している人にとって、これはあなたのための情報です。MultipleBaseAddressBasicHttpBindingServiceHostFactoryを使用している場合、他のサイト/投稿で提案されているアプリケーションホストとweb.configの設定がSharePointで機能しません。SP Powershellを使用してSPWebService.Contentサービスを取得し、新しいSPWcvSettingsオブジェクトを作成して、サービスの設定を上記のように更新します（これらは存在しません）。設定を作成および追加するときは、サービスの名前（[yourservice.svc]など）を使用することを忘れないでください。詳細については、このサイトを参照してくださいhttps://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service

私の場合、BizTalkの受信場所の「最大受信メッセージサイズ」を増やす必要がありました。また、64Kのデフォルト値があるため、web.configで何を設定したかに関係なく、すべてのメッセージがBizTAlkによってバウンスされました。

同じwcfチャネル/クライアントで大量のコンテンツを含むリクエストの直前にダミーコール（IsAliveがtrueを返すなど）を実行することで、これを解決できました。どうやらsslネゴシエーションは最初の呼び出しで行われます。したがって、Uploadreadaheadsizeを増やす必要はありません。

問題のリモートサーバーが予期しない応答を返しました：（413）Resfulを使用したWCFでエンティティが大きすぎる要求

私の説明設定を参照してください

</client>
<serviceHostingEnvironment multipleSiteBindingsEnabled="false" aspNetCompatibilityEnabled="true"/>

<bindings>

   <!-- this for restfull service -->
  <webHttpBinding>
    <binding name="RestfullwebHttpBinding"
      maxBufferPoolSize="2147483647"
      maxReceivedMessageSize="2147483647"
      maxBufferSize="2147483647" transferMode="Streamed">

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

    </binding>
  </webHttpBinding>
  <!-- end -->

   <!-- this for Soap v.2 -->
  <wsHttpBinding>
    <binding name="wsBinding1" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
      <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
      <!--UsernameToken over Transport Security-->
      <security mode="TransportWithMessageCredential">
        <message clientCredentialType="UserName" establishSecurityContext="true"/>
      </security>
    </binding>
  </wsHttpBinding>
   <!-- this for restfull service -->

   <!-- this for Soap v.1 -->
  <basicHttpBinding>
    <binding name="basicBinding1" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false" transferMode="Streamed">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
      <security mode="None"/>
    </binding>
  </basicHttpBinding>
</bindings> 
<!-- end -->

<services>
  <clear/>

  <service name="ING.IWCFService.CitisecHashTransfer"  >
    <endpoint address="http://localhost:8099/CitisecHashTransfer.svc"
                  behaviorConfiguration="RestfullEndpointBehavior"
                  binding="webHttpBinding"
                  bindingConfiguration="RestfullwebHttpBinding"
                  name="ICitisecHashTransferBasicHttpBinding"
                  contract="ING.IWCFService.ICitisecHashTransfer" />
  </service>

</services>
<behaviors>
  <serviceBehaviors>
    <behavior name="ServiceBehavior">
      <serviceMetadata httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <dataContractSerializer maxItemsInObjectGraph="2147483647"/>

      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="ING.IWCFService.IWCFServiceValidator, ING.IWCFService"/>
      </serviceCredentials>
      <serviceSecurityAudit auditLogLocation="Application" serviceAuthorizationAuditLevel="SuccessOrFailure" messageAuthenticationAuditLevel="SuccessOrFailure"/>
      <serviceThrottling maxConcurrentCalls="1000" maxConcurrentSessions="100" maxConcurrentInstances="1000"/>

    </behavior>
    <behavior>
      <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
    </behavior>
  </serviceBehaviors>
  <endpointBehaviors>
    <behavior name="EndpointBehavior">
      <dataContractSerializer maxItemsInObjectGraph="2147483647" />
    </behavior> 
    <behavior name="RestfullEndpointBehavior">
      <dataContractSerializer maxItemsInObjectGraph="2147483647"  />
      <webHttp/>
    </behavior> 
  </endpointBehaviors>
</behaviors>

私の場合、サービスのネームスペースが変更され、サービスタグが古いネームスペースをポイントしていたため、このエラーメッセージが表示されました。名前空間を更新すると、エラーが表示されなくなりました。

<services>
  <service name="My.Namespace.ServiceName"> <!-- Updated name -->
    <endpoint address="" 
              binding="wsHttpBinding" 
              bindingConfiguration="MyBindingConfiguratioName" 
              contract="My.Namespace.Interface" <!-- Updated contract -->
    />
  </service>
</services>

Visual Studio 2017を使用するIIS Expressで同様のエラーが発生しました。

HTTPエラー413.0-要求エンティティが大きすぎます

リクエストエンティティが大きすぎるため、ページは表示されませんでした。

最も考えられる原因：

• 要求エンティティが大きすぎるため、Webサーバーは要求の処理を拒否しています。

• Webサーバーはクライアント証明書をネゴシエートしようとしているが、要求エンティティが大きすぎるため、要求を処理できません。

• 要求URLまたはURLへの物理マッピング（つまり、URLのコンテンツへの物理ファイルシステムパス）が長すぎます。

あなたが試すことができるもの：

• 要求が有効であることを確認してください。

• クライアント証明書を使用している場合は、以下を試してください。

  • system.webServer/serverRuntime@uploadReadAheadSizeを増やす

  • 最初のSSLハンドシェイクの一部としてクライアント証明書をネゴシエートするようにSSLエンドポイントを構成します。（netsh http add sslcert ... clientcertnegotiation = enable）.vs \ config \ applicationhost.config

編集してこれを解決します\.vs\config\applicationhost.config。スイッチserverRuntimeからDenyのAllowこのような：

<section name="serverRuntime" overrideModeDefault="Allow" />

この値を編集しないと、設定時に次のようなエラーが発生しますuploadReadAheadSize。

HTTPエラー500.19-内部サーバーエラー

ページの関連構成データが無効であるため、要求されたページにアクセスできません。

この構成セクションは、このパスでは使用できません。これは、セクションが親レベルでロックされている場合に発生します。ロックは、デフォルト（overrideModeDefault = "Deny"）か、overrideMode = "Deny"または従来のallowOverride = "false"を指定した場所タグによって明示的に設定されます。

次にWeb.config、次の値で編集します。

<system.webServer>
  <serverRuntime uploadReadAheadSize="10485760" />
...