(413) Anforderungsentität zu groß | uploadReadAheadSize

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?

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>

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>

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 .

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

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.

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

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

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

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

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.

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>

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>

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