it-swarm.com.de

(413) Zu große Entität anfordern | uploadReadAheadSize

Ich habe einen WCF-Dienst mit .NET 4.0 geschrieben, der auf meinem Windows 7 x64 Ultimate-System mit IIS 7.5 ..__ gehostet wird. Eine der Dienstmethoden hat ein 'Objekt' als Argument und ich versuche es ein Byte [] senden, das ein Bild enthält ..__ Solange die Dateigröße dieses Bildes weniger als ca. 48 KB, alles geht gut. Wenn ich versuche, ein größeres Bild hochzuladen, gibt der WCF-Dienst eine Fehlermeldung aus: (413) Request Entity Too Large.So habe ich 3 Stunden damit verbracht, die Fehlermeldung zu googeln und jedes Thema, das ich zu diesem Thema gesehen habe, schlägt vor, 'uploadReadAheadSize' anzuheben 'property . Also habe ich folgende Befehle benutzt (10485760 = 10MB):

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

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

Ich habe auch den IIS - Manager verwendet, um den Wert festzulegen, indem Sie die Site öffnen und unter "Verwaltung ..." in den "Konfigurationseditor" gehen. Leider bekomme ich immer noch den Request Entity Too Large-Fehler und es wird wirklich frustrierend!

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

121
kipusoep

Das ist kein Problem von IIS, sondern das Problem von WCF. WCF begrenzt standardmäßig Nachrichten auf 65 KB, um Denial-of-Service-Angriffe mit umfangreichen Nachrichten zu vermeiden. Wenn Sie kein MTOM verwenden, sendet es Byte [] an die Base64-kodierte Zeichenfolge (Vergrößerung um 33%) => 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 hat zuvor den Fehler "400 Bad Request" ausgelöst. In der neueren Version begann WCF jedoch, 413 zu verwenden. Dies ist der korrekte Statuscode für diese Art Fehler.

Sie müssen maxReceivedMessageSize in Ihrer Bindung festlegen. Sie können auch readerQuotas einstellen.

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

Ich hatte das gleiche Problem mit IIS 7.5 mit einem WCF REST - Dienst. Beim Versuch, über POST eine Datei über 65 KB hochzuladen, wird Fehler 413 "Request Entity too large" zurückgegeben.

Als Erstes müssen Sie verstehen, welche Art von Bindung Sie in der web.config konfiguriert haben. Hier ist ein toller Artikel ...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Wenn Sie einen REST - Dienst haben, müssen Sie ihn als "webHttpBinding" konfigurieren. Hier ist der Fix:

<system.serviceModel>

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

Ich hatte das gleiche Problem und das Einstellen der uploadReadAheadSize hat es gelöst:

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

"Der Wert muss zwischen 0 und 2147483647 liegen."

Es kann einfach in der applicationHost.config-fle gesetzt werden, wenn Sie kein cmd-Ding machen möchten.

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

Sie müssen es mit dem Notizblock öffnen. Führen Sie zuerst ein Backup der Datei durch.

Den Kommentaren in config zufolge empfiehlt es sich, Abschnitte mit einem Standort-Tag 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 maxvalue hier - schreibe deinen eigenen Wert, wenn du willst.

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

Wenn Sie es beispielsweise vor </configuration> 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, was zu einem (413) Request Entity Too Large -Fehler führte.

24
Tom P

Ich habe diese Fehlermeldung erhalten, obwohl die max-Einstellungen in der Bindung meiner WCF-Service-Konfigurationsdatei 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 ob diese Bindungseinstellungen nicht angewendet würden, daher die folgende Fehlermeldung:

IIS7 - (413) Request Entity Too Large, wenn Sie sich mit dem Dienst verbinden.

.

Das Problem

Ich erkannte, dass das name=""-Attribut im <service>-Tag des web.confignicht ein Freitextfeld ist, wie ich es mir vorgestellt hatte. Es ist der vollständig qualifizierter Name einer Implementierung eines Servicevertrags wie auf dieser Dokumentationsseite erwähnt.

Wenn das nicht passt, 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 Schmerzen ...

12
Luke

Dies half mir, das Problem zu lösen (eine Zeile - zwecks Lesbarkeit/Kopierbarkeit aufgeteilt):

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

Wenn dieses Problem auftritt, obwohl Sie alle Lösungen in diesem Thread ausprobiert haben und Sie über SSL (z. B. https) eine Verbindung zum Dienst herstellen, kann dies Folgendes helfen:

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

Zusammenfassend (falls der Link in der Zukunft nicht mehr funktioniert): Wenn Ihre Anforderungen groß genug sind, schlägt die Zertifikataushandlung zwischen dem Client und dem Dienst zufällig fehl. Um dies zu verhindern, müssen Sie eine bestimmte Einstellung für Ihre SSL-Bindungen aktivieren. Hier sind die Schritte, die Sie von Ihrem IIS Server ausführen müssen:

  1. Führen Sie über cmd oder powershell netsh http show sslcert aus. Dadurch erhalten Sie Ihre aktuelle Konfiguration. Sie möchten dies irgendwie speichern, damit Sie es später erneut referenzieren können.
  2. Sie sollten beachten, dass "Negotiate Client Certificate" deaktiviert ist. Dies ist die Problemeinstellung; Die folgenden Schritte zeigen, wie Sie es aktivieren können.
  3. Leider gibt es keine Möglichkeit, vorhandene Bindungen zu ändern. Sie müssen es löschen und erneut hinzufügen. Führen Sie netsh http delete sslcert <ipaddress>:<port> aus, wobei <ipaddress>:<port> der IP: Port ist, 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 sslcerthier (MSDN) anzeigen. In den meisten Fällen sieht Ihr Befehl jedoch so 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 einzelne. Hoffentlich hilft mir das, die vielen Stunden und Kopfschmerzen zu retten, die dieses Problem verursacht hat.

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

4
oconnerj

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

1
Riccardo Gozzi

Für mich wurde das Problem auch durch das Setzen der uploadReadAheadSize auf int.MaxValue behoben, nachdem auch die Grenzen der WCF-Bindung erhöht wurden.

Es scheint, dass bei Verwendung von SSL der gesamte Anforderungsentitätskörper vorab geladen wird, für den diese Metabase-Eigenschaft verwendet wird.

Weitere Informationen finden Sie unter:

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

1
revers

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

1
Han Evers

Ich konnte dieses Problem lösen, indem ich einen Dummy-Aufruf ausführte (z. B. IsAlive, der true zurückgibt), kurz bevor die Anforderung mit großem Inhalt auf demselben WCF-Kanal/-Client ausgeführt wird. Anscheinend wird beim ersten Aufruf eine SSL-Verhandlung durchgeführt. Daher muss Uploadreadaheadsize nicht erhöht werden. 

0
rekna

Es wurde ein ähnlicher Fehler in IIS Express mit Visual Studio 2017 angezeigt. 

HTTP-Fehler 413.0 - Zu große Entität anfordern

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

Wahrscheinlichste Gründe:

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

  • Der Webserver kann die Anforderung nicht bearbeiten, da er versucht, __. Verhandeln Sie ein Client-Zertifikat, aber die Anforderungsentität ist zu groß.

  • Die Anforderungs-URL oder die physische Zuordnung zu der URL (d. H. Dem physischen Dateisystempfad 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:

    • System.webServer/[email protected] erhöhen

    • Konfigurieren Sie Ihren SSL-Endpunkt für das Aushandeln von Clientzertifikaten als Teil des ersten SSL-Handshakes. (netsh http add sslcert ... clientcertnegotiation = enable) .vs\config\applicationhost.config

Lösen Sie dies, indem Sie \.vs\config\applicationhost.config bearbeiten. Wechseln Sie serverRuntime von Deny zu Allow wie folgt:

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

Wenn dieser Wert nicht bearbeitet wird, erhalten Sie eine solche Fehlermeldung, wenn Sie uploadReadAheadSize einstellen:

HTTP-Fehler 500.19 - Interner Serverfehler 

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

Dieser Konfigurationsabschnitt kann auf diesem Pfad nicht verwendet werden. Das passiert wenn der Abschnitt auf übergeordneter Ebene gesperrt ist. Die Sperrung erfolgt entweder durch default (overrideModeDefault = "Deny") oder explizit durch einen Speicherort festgelegt Tag mit overrideMode = "Deny" oder dem veralteten allowOverride = "false".

Bearbeiten Sie dann Web.config mit den folgenden Werten: 

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

In meinem Fall wurde diese Fehlermeldung angezeigt, weil der Namespace des Services geändert wurde und das Service-Tag auf den älteren Namespace verweist. 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>
0

für ein Problem hat der Remote-Server eine unerwartete Antwort zurückgegeben: (413) Request Entity Too Large auf WCF mit Resful

bitte sehen sie meine erklärungskonfiguration

 

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

0
asawin