(413) リクエストエンティティが大きすぎる｜uploadReadAheadSize

私は.NET 4.0でWCFサービスを書き、IIS 7.5を備えたWindows 7 x64 Ultimateシステムでホストしています。 サービスメソッドの1つは 'object' を引数として持ち、私は画像を含むbyte[]を送信しようとしています。 この画像のファイルサイズが約48KB以下である限り、すべてがうまくいきます。しかし、もっと大きな画像をアップロードしようとすると、WCFサービスは (413) Request Entity Too Large. というエラーを返します。 もちろん、このエラーメッセージについて3時間ほどググってみたのですが、このテーマについて見たすべてのトピックは 'uploadReadAheadSize' プロパティを上げることを示唆しています。 そこで、私が行ったのは以下のコマンドです（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というエラーはまだ出ていて、本当にイライラしています。

そこで、このエラーを解決するために他に何を試せばよいか、どなたかご存知でしょうか？

Uwe Keim
編集された質問 17日 4月 2018 в 9:29
プログラミング
wcf iis
12日 4月 2012 в 11:49
187 ビュー
質問へのコメント (1)
ソリューション

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

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

バインディングで maxReceivedMessageSize を設定する必要があります。また、readerQuotas を設定する必要があります。
解説 (10)

IIS 7.5でWCF REST Serviceを使用していて同じ問題がありました。65k以上のファイルをPOSTでアップロードしようとすると、エラー413 "リクエストエンティティが大きすぎます"が返されました。

まず最初に理解しなければならないのは、web.configでどのようなバインディングが設定されているかです。ここに素晴らしい記事があります...

https://stackoverflow.com/questions/2650785/basichttpbinding-vs-wshttpbinding-vs-webhttpbinding

もしRESTサービスを持っているならば、それを"webHttpBinding"として構成する必要があります。以下はその修正方法です。
Community
編集した答え 23日 5月 2017 в 10:31
解説 (5)

私も同じ問題で、uploadReadAheadSizeを設定することで解決しました。

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

"値は0から2147483647の間である必要があります.&quot。

cmdで設定するのが面倒な場合は、applicationHost.config-fleで簡単に設定することができます。

WindowsFOLDERのSystem32にある "inetsrv "コンフィグ(2008 server)にある。

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

configのコメントによると、セクションのロックを解除するには、ロケーションタグを使用することが推奨されています。





"

ということで、一番下に書き込むことができます（以前は存在しないので）。ここでは maxvalue と書いていますが、お好みで値を書いてください。

例えば、``の前に最後に置くと、どこに置いてあるのかが分かります。

これで問題が解決するといいのですが。私の場合はSSLのオーバーヘッドの問題で、ポストが多すぎるとアプリケーションがフリーズして (413) Request Entity Too Large というエラーが発生しました。

abatishchev
編集した答え 8日 4月 2016 в 11:51
解説 (3)

WCFサービス構成ファイルのバインディング内に「最大」設定が設定されていても、このエラーメッセージを受信していました。

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

IIS7-(413)サービスに接続するときにエンティティが大きすぎるリクエスト。

. 問題。 -----------。

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

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

それが誰かに苦痛を与えることを願っています。..

解説 (2)

これは問題の解決に役立ちました(1行-読みやすさ/コピー可能性の分割):

C:\Windows\System32\inetsrv\appcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost
Anthony Horne
編集した答え 18日 2月 2016 в 1:43
解説 (1)

このスレッドのすべてのソリューションを試してもこの問題が発生し、SSLを介してサービスに接続している場合(例:. https)、これは役立つかもしれません:

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

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

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

netsh http add sslcert ipport =< ipaddress>:< port> appid =< {{{}}}>を含む保存された構成からのアプリケーションID保存された構成からのcerthash =< certificate hash> certstorename =< clientcertnegotiation = enable。

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

EDIT:私の経験では、コマンドラインから「netsh http add sslcert」コマンドを直接実行することはできません。 最初に「netsh」と入力してnetshプロンプトを入力し、次に「http add sslcert ipport =」のようなコマンドを発行する必要があります。..`機能するために。

oconnerj
編集した答え 8日 4月 2016 в 1:45
解説 (1)

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

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

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

https://stackoverflow.com/questions/22762311/the-page-was-not-displayed-because-the-request-entity-is-too-large-iis7。

解説 (1)

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。

解説 (0)

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

解説 (0)

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」を編集します。



...
Ogglas
編集した答え 25日 2月 2019 в 7:07
解説 (0)

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

解説 (0)

発行のため、リモートサーバーは予期しない応答を返しました:(413)Resfulを使用してWCFでエンティティが大きすぎるリクエスト。

私の説明の構成を参照してください。

< system.serviceModel>。 < client>。

< / system.serviceModel>。

解説 (0)

私の場合、サービスの名前空間を変更し、サービスタグを古い名前空間に向けると、このエラーメッセージが表示されました。 名前空間を更新し、エラーが消えます:




    /
解説 (0)