(413) Anforderungsentität zu groß | uploadReadAheadSize

136

Ich habe einen WCF-Dienst mit .NET 4.0 geschrieben, der auf meinem Windows 7 x64Ultimate-System mit IIS 7.5 gehostet wird . Eine der Dienstmethoden hat ein 'Objekt' als Argument und ich versuche, ein Byte [] zu senden, das ein Bild enthält. Solange die Dateigröße dieses Bildes weniger als ca. 48KB, alles geht gut. Wenn ich jedoch versuche, ein größeres Bild hochzuladen, gibt der WCF-Dienst einen Fehler zurück: (413) Request Entity Too Large. Natürlich habe ich 3 Stunden damit verbracht, die Fehlermeldung zu googeln, und jedes Thema, das ich zu diesem Thema gesehen habe, schlägt vor, die Eigenschaft 'uploadReadAheadSize' zu erhöhen. Ich habe also die folgenden Befehle verwendet (10485760 = 10 MB):

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

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

Ich habe auch IIS Manager verwendet, um den Wert festzulegen, indem ich die Site öffne und unter Verwaltung zu "Konfigurationseditor" gehe. Leider erhalte ich immer noch den Fehler Request Entity Too Large und es wird wirklich frustrierend!

Weiß jemand, was ich sonst noch versuchen kann, um diesen Fehler zu beheben?

kipusoep
quelle
6
10485760 = 10 MB, nicht 1 MB
Shaun Rowan

Antworten:

206

Das ist kein Problem von IIS, sondern das Problem von WCF. WCF beschränkt Nachrichten standardmäßig auf 65 KB, um Denial-of-Service-Angriffe mit großen Nachrichten zu vermeiden. Auch wenn Sie kein MTOM verwenden, wird Byte [] an einen Base64-codierten String gesendet (33% mehr Größe) => 48 KB * 1,33 = 64 KB

Um dieses Problem zu beheben, müssen Sie Ihren Dienst neu konfigurieren, um größere Nachrichten zu akzeptieren. Dieses Problem löste zuvor einen 400 Bad Request-Fehler aus, aber in der neueren Version verwendete WCF 413, den korrekten Statuscode für diesen Fehlertyp.

Sie müssen maxReceivedMessageSizeIhre Bindung festlegen . Möglicherweise müssen Sie auch einstellen readerQuotas.

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding maxReceivedMessageSize="10485760">
        <readerQuotas ... />
      </binding>
    </basicHttpBinding>
  </bindings>  
</system.serviceModel>
Ladislav Mrnka
quelle
8
Ich habe die maxRecievedMessageSize auf den obigen Wert gesetzt, aber ich erhalte immer noch den gleichen Fehler. Anfrage Entität ist zu groß.
Sandepku
11
@ Sandepku- Nur für den Fall ... Ich hatte lange Zeit das gleiche Problem und stellte dann fest, dass ich den Bindungsnamen falsch benannt hatte, sodass WCF die Standardwerte anstelle meiner Konfigurationswerte verwendete und mir die genauen Werte gab gleicher Fehler.
Adrian Carr
1
Ich habe die maxRecievedMessageSize auf den obigen Wert gesetzt, aber ich erhalte immer noch den gleichen Fehler. Die Anforderungsentität ist zu groß. Der Bindungsname ist nicht leer. Hilfe!
NetSide
2
Vielen Dank, Sir, das war sofort hilfreich! Zum Festlegen eines neuen Werts für maxReceivedMessageSize muss derselbe Wert für maxBufferSize festgelegt werden.
DiligentKarma
1
@ Sandpku Wenn Sie webhttpbinding für REST verwenden, müssen Sie möglicherweise den Bindungsnamen in <Bindung> gleich der Bindungskonfiguration in <Endpunkt> machen
Smoothumut
55

Ich hatte das gleiche Problem mit IIS 7.5 mit einem WCF-REST-Service. Wenn Sie versuchen, eine Datei über 65 KB per POST hochzuladen, wird der Fehler 413 "Anforderungsentität zu groß" zurückgegeben.

Das erste, was Sie verstehen müssen, ist, welche Art von Bindung Sie in der web.config konfiguriert haben. Hier ist ein großartiger Artikel ...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Wenn Sie einen REST-Service haben, müssen Sie ihn als "webHttpBinding" konfigurieren. Hier ist das Update:

<system.serviceModel>

<bindings>
   <webHttpBinding>
    <binding 
      maxBufferPoolSize="2147483647" 
      maxReceivedMessageSize="2147483647" 
      maxBufferSize="2147483647" transferMode="Streamed">
    </binding>  
   </webHttpBinding>
</bindings>
Robert Barrueco
quelle
2
Vielen Dank, dies hat bei Verwendung von IIS 7.5 mit einem WCF-REST-Service funktioniert. Tatsächlich musste ich nur das Attribut maxReceivedMessageSize ändern.
Alex Yuly
Ich hatte die maxReceivedMessageSize, die maxBufferSize hat den Trick gemacht, maxBufferPoolSize wurde als ungültiges Attribut angezeigt.
JabberwockyDecompiler
4
Stellen Sie sicher, dass Sie den Bindungsnamen definieren und ihn der Bindungskonfiguration auf dem Endpunkt entsprechen. Beispiel: <binding name = "restLargeBinding" maxBufferPoolSize = ..........>. Und in der Servicekonfiguration; <Endpoint Address = "" Binding = "WebHttpBinding" BindingConfiguration = "RestLargeBinding" .......
Smoothumut
2
funktioniert super, obwohl das Setzen des transferMode = "Streamed" mir eine schlechte Anfrage gab, musste diese entfernen
WtFudgE
1
@smoothumut Ich weiß, dass es alt ist, aber die bindingConfiguration = "restLargeBinding" hat den Trick für mich getan! Übrigens benutze ich einen selbst gehosteten wcf-Dienst.
Ramires.cabral
26

Ich hatte das gleiche Problem und stellte das Problem ein uploadReadAheadSize:

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

"Der Wert muss zwischen 0 und 2147483647 liegen."

Es kann einfach in der applicationHost.config-fle festgelegt werden, wenn Sie keine cmd-Sache machen möchten.

Es befindet sich in WindowsFOLDER\System32\inetsrv\config(2008 Server).

Sie müssen es mit dem Editor öffnen. Führen Sie zuerst eine Sicherung der Datei durch.

Gemäß den Kommentaren in der Konfiguration wird empfohlen, Abschnitte mithilfe eines Standort-Tags zu entsperren:

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

Sie können also unten schreiben (da es vorher nicht existiert). Ich schreibe maxvaluehier - schreibe deinen eigenen Wert, wenn du willst.

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

Wenn Sie es </configuration>zum Beispiel vorher setzen , wissen Sie, wo Sie es haben.

Hoffe das löst deine Probleme. Es war ein SSL-Overhead-Problem für mich, bei dem zu viel Post die Anwendung einfrierte und einen (413) Request Entity Too Large- Fehler auslöste .

Tom P.
quelle
1
Nachdem dies bereits maxReceivedMessageSizeauf int.MaxValue eingestellt war, war dies der Trick. Ich frage mich, ob es größere Bedenken gibt, diese Option auch auf int.MaxValue zu setzen.
Langdon
2
Würde jemand wissen, ob uploadReadAheadSize auch für selbst gehostete WCF-Dienste relevant ist, die nicht über IIS ausgeführt werden? Ist dies auch ein Problem im Zusammenhang mit Windows Server im Allgemeinen?
Ameisencode
@antscode Ich habe eine selbst gehostete API und habe das gleiche Problem - haben Sie es mit Ihrem selbst gehosteten Dienst gelöst?
Trevor Daniel
17

Ich habe diese Fehlermeldung erhalten, obwohl die maxEinstellungen in der Bindung meiner WCF-Dienstkonfigurationsdatei festgelegt wurden:

<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>

Es schien, als würden diese Bindungseinstellungen nicht angewendet, daher die folgende Fehlermeldung:

IIS7 - (413) Anforderungsentität zu groß, wenn eine Verbindung zum Dienst hergestellt wird.

.

Das Problem

Ich erkennen , dass das name=""Attribut im <service>Tag von dem web.configist nicht ein Freitextfeld, wie ich dachte , es wäre. Dies ist der vollständig qualifizierte Name einer Implementierung eines Servicevertrags, wie auf dieser Dokumentationsseite angegeben .

Wenn dies nicht übereinstimmt, werden die Bindungseinstellungen nicht angewendet!

<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>

Ich hoffe das erspart jemandem etwas Schmerz ...

Luke
quelle
1
Vielen Dank, dass Sie diese Lösung hinzugefügt haben! Indirekt löste sich mein Problem dadurch, dass sich mein Vertragsname in dev änderte, die Änderung jedoch nicht ordnungsgemäß für die Produktion bereitgestellt wurde. Durch Überprüfen dieser Einstellung wurden meine (413) Fehler bei der Anforderungsentität zu groß behoben, da die Standardeinstellungen für die Nachrichtengröße verwendet wurden.
Doug Knudsen
Ich bin wirklich froh, dass dies jemandem geholfen hat. Ich habe eine Weile damit verbracht, also hoffte ich, dass es jemandes Tag weniger schmerzhaft machen würde.
Luke
9

Wenn Sie auf dieses Problem stoßen, obwohl Sie alle Lösungen in diesem Thread ausprobiert haben und über SSL (z. B. https) eine Verbindung zum Dienst herstellen, kann dies hilfreich sein:

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

Zusammenfassend lässt sich sagen, dass die Zertifikatsaushandlung zwischen dem Client und dem Dienst zufällig fehlschlägt, wenn Ihre Anforderungen groß genug sind (falls der Link in Zukunft nicht mehr funktioniert). Um dies zu verhindern, müssen Sie eine bestimmte Einstellung für Ihre SSL-Bindungen aktivieren. Auf Ihrem IIS-Server müssen Sie folgende Schritte ausführen:

  1. Über cmd oder Powershell laufen netsh http show sslcert. Dadurch erhalten Sie Ihre aktuelle Konfiguration. Sie möchten dies irgendwie speichern, damit Sie später erneut darauf verweisen können.
  2. Sie sollten beachten, dass "Client-Zertifikat aushandeln" deaktiviert ist. Dies ist die Problemeinstellung. Die folgenden Schritte zeigen, wie Sie es aktivieren.
  3. Leider gibt es keine Möglichkeit, vorhandene Bindungen zu ändern. Sie müssen es löschen und erneut hinzufügen. Führen Sie aus, netsh http delete sslcert <ipaddress>:<port>wo <ipaddress>:<port>sich der IP: -Port befindet, der in der zuvor gespeicherten Konfiguration angezeigt wird.
  4. Jetzt können Sie die Bindung erneut hinzufügen. Sie können die gültigen Parameter für netsh http add sslcert hier (MSDN) anzeigen, aber in den meisten Fällen sieht Ihr Befehl folgendermaßen aus:

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

Wenn Sie mehrere SSL-Bindungen haben, wiederholen Sie den Vorgang für jede dieser Bindungen. Hoffentlich hilft dies, jemand anderem die Stunden und Stunden der Kopfschmerzen zu ersparen, die mir dieses Problem verursacht hat.

BEARBEITEN: Nach meiner Erfahrung können Sie netsh http add sslcertden Befehl nicht direkt über die Befehlszeile ausführen . Sie müssen zuerst die Eingabeaufforderung netsh eingeben, indem Sie Folgendes eingeben netshund dann Ihren Befehl wie folgt ausgeben http add sslcert ipport=..., damit er funktioniert.

oconnerj
quelle
Vielen Dank für den Beitrag, der dazu beigetragen hat, das Problem für uns zu isolieren. Durch Deaktivieren von SSL wird der WCF-Fehler behoben. Leider hat die Clientcertnegotiation unser Ergebnis nicht dahingehend geändert, dass es über SSL funktioniert. Stil auf der Suche nach anderen Bits zum Umschalten :-(
Jafin
8

Dies hat mir geholfen, das Problem zu lösen (eine Zeile - aufgeteilt auf Lesbarkeit / Kopierbarkeit):

C:\Windows\System32\inetsrv\appcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost
Anas
quelle
Hosten Sie Ihre WCF in der SharePoint-Umgebung? und mussten Sie Ihren IIS neu starten, nachdem Sie die Änderungen übernommen haben?
theITvideos
2

Für mich hat das Setzen uploadReadAheadSizevon int.MaxValue auch das Problem behoben, nachdem auch die Grenzen für die WCF-Bindung erhöht wurden.

Es scheint, dass bei Verwendung von SSL der gesamte Body der Anforderungsentität vorinstalliert ist, für den diese Metabase-Eigenschaft verwendet wird.

Weitere Informationen finden Sie unter:

Die Seite wurde nicht angezeigt, da die Anforderungsentität zu groß ist. iis7

Revers
quelle
1
Ihre Erkenntnisse zu SSL und 'uploadReadAheadSize' sind sehr gut! .. Aber ich empfehle nicht, es auf den Maximalwert zu setzen
Lerner
1

Für alle anderen, die jemals nach einem IIS-WCF-Fehler gesucht haben 413: Entität zu groß anfordern und einen WCF-Dienst in Sharepoint verwenden, sind dies die Informationen für Sie. Die auf anderen Websites / Posts vorgeschlagenen Einstellungen im Anwendungshost und in der Datei web.config funktionieren in SharePoint nicht, wenn MultipleBaseAddressBasicHttpBindingServiceHostFactory verwendet wird. Sie können SP Powershell verwenden, um den SPWebService.Content-Dienst abzurufen, ein neues SPWcvSettings-Objekt zu erstellen und die Einstellungen wie oben für Ihren Dienst zu aktualisieren (sie sind nicht vorhanden). Denken Sie daran, beim Erstellen und Hinzufügen der Einstellungen nur den Namen des Dienstes (z. B. [yourservice.svc]) zu verwenden. Weitere Informationen finden Sie auf dieser Website unter https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service

Riccardo Gozzi
quelle
1

In meinem Fall musste ich die "Maximal empfangene Nachrichtengröße" des Empfangsspeicherorts in BizTalk erhöhen. Das hat auch einen Standardwert von 64K und so wurde jede Nachricht von BizTAlk zurückgesendet, unabhängig davon, was ich in meiner web.config konfiguriert habe

Han Evers
quelle
1

Ich konnte dies lösen, indem ich einen Dummy-Aufruf (z. B. IsAlive, der true zurückgibt) unmittelbar vor der Anforderung mit großem Inhalt auf demselben wcf-Kanal / Client ausführte. Anscheinend wird die SSL-Verhandlung beim ersten Anruf durchgeführt. Sie müssen also die Größe von Uploadreadaheads nicht erhöhen.

rekna
quelle
0

Für ein Problem hat der Remoteserver eine unerwartete Antwort zurückgegeben: (413) Anforderungsentität zu groß auf WCF mit Resful

Bitte beachten Sie meine Konfiguration erklären

</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>

asawin
quelle
0

In meinem Fall wurde diese Fehlermeldung angezeigt, weil der Namespace des Dienstes geändert wurde und das Dienst-Tag auf den älteren Namespace verwiesen wurde. Ich habe den Namespace aktualisiert und der Fehler verschwindet:

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

In IIS Express mit Visual Studio 2017 ist ein ähnlicher Fehler aufgetreten.

HTTP-Fehler 413.0 - Anforderungsentität zu groß

Die Seite wurde nicht angezeigt, da die Anforderungsentität zu groß ist.

Wahrscheinlichste Gründe:

  • Der Webserver weigert sich, die Anforderung zu bearbeiten, da die Anforderungsentität zu groß ist.

  • Der Webserver kann die Anforderung nicht bearbeiten, da er versucht, ein Clientzertifikat auszuhandeln, die Anforderungsentität jedoch zu groß ist.

  • Die Anforderungs-URL oder die physische Zuordnung zur URL (dh der Pfad des physischen Dateisystems zum Inhalt der URL) ist zu lang.

Dinge, die Sie ausprobieren können:

  • Stellen Sie sicher, dass die Anforderung gültig ist.

  • Wenn Sie Client-Zertifikate verwenden, versuchen Sie Folgendes:

    • Erhöhen von system.webServer/serverRuntime@uploadReadAheadSize

    • Konfigurieren Sie Ihren SSL-Endpunkt so, dass Clientzertifikate im Rahmen des ersten SSL-Handshakes ausgehandelt werden. (netsh http add sslcert ... clientcertnegotiation = enable) .vs \ config \ applicationhost.config

Lösen Sie dies durch Bearbeiten \.vs\config\applicationhost.config. Wechseln Sie serverRuntimevon Denyzu Allowwie folgt:

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

Wenn dieser Wert nicht bearbeitet wird, wird beim Einstellen uploadReadAheadSizefolgende Fehlermeldung angezeigt :

HTTP-Fehler 500.19 - Interner Serverfehler

Auf die angeforderte Seite kann nicht zugegriffen werden, da die zugehörigen Konfigurationsdaten für die Seite ungültig sind.

Dieser Konfigurationsabschnitt kann unter diesem Pfad nicht verwendet werden. Dies geschieht, wenn der Abschnitt auf übergeordneter Ebene gesperrt ist. Das Sperren erfolgt entweder standardmäßig (overrideModeDefault = "Deny") oder wird explizit durch ein Standort-Tag mit overrideMode = "Deny" oder dem Legacy allowOverride = "false" festgelegt.

Bearbeiten Sie dann Web.configmit den folgenden Werten:

<system.webServer>
  <serverRuntime uploadReadAheadSize="10485760" />
...
Ogglas
quelle
Wenn Sie abstimmen, sagen Sie bitte warum. Ansonsten ist es sehr schwer, die Antworten zu verbessern.
Ogglas