(413) Entità richiesta troppo grande | uploadReadAheadSize


136

Ho scritto un servizio WCF con .NET 4.0, che è ospitato sul mio sistema Windows 7 x64Ultimate con IIS 7.5. Uno dei metodi di servizio ha un 'oggetto' come argomento e sto cercando di inviare un byte [] che contiene un'immagine. Finché la dimensione del file di questa immagine è inferiore a ca. 48KB, tutto va bene. Ma se sto cercando di caricare un'immagine più grande, il servizio WCF restituisce un errore: (413) Request Entity Too Large. quindi ovviamente ho trascorso 3 ore a cercare su Google il messaggio di errore e ogni argomento che ho visto su questo argomento suggerisce di aumentare la proprietà 'uploadReadAheadSize'. Quindi quello che ho fatto è usare i seguenti comandi (10485760 = 10 MB):

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

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

Ho anche usato Gestione IIS per impostare il valore aprendo il sito e andando su "Editor di configurazione" in Gestione. Sfortunatamente sto ancora ricevendo l'errore Richiesta entità troppo grande e sta diventando davvero frustrante!

Qualcuno sa cos'altro posso provare a correggere questo errore?


6
10485760 = 10 MB, non 1 MB
Shaun Rowan,

Risposte:


206

Questo non è un problema di IIS ma il problema di WCF. Per impostazione predefinita, WCF limita i messaggi a 65 KB per evitare attacchi denial of service con messaggi di grandi dimensioni. Inoltre, se non si utilizza MTOM, invia byte [] alla stringa codificata base64 (aumento del 33% delle dimensioni) => 48 KB * 1,33 = 64 KB

Per risolvere questo problema, è necessario riconfigurare il servizio per accettare messaggi più grandi. Questo problema in precedenza aveva generato l'errore 400 Bad Request ma nella versione più recente WCF ha iniziato a utilizzare 413 che è il codice di stato corretto per questo tipo di errore.

Devi impostare la maxReceivedMessageSizetua rilegatura. È inoltre possibile impostare readerQuotas.

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

8
ho impostato maxRecievedMessageSize sul valore sopra riportato, ma ho ancora lo stesso errore. L'entità richiesta è troppo grande ..
Sandepku,

11
@ Sandepku- Per ogni evenienza ... Ho avuto lo stesso problema per un bel po 'di tempo, e poi ho capito che avevo erroneamente chiamato il Binding Name, quindi WCF stava usando i valori di default invece dei miei valori di configurazione, e mi stava dando l'esatto stesso errore.
Adrian Carr,

1
ho impostato maxRecievedMessageSize sul valore sopra, ma ho ancora lo stesso errore. L'entità richiesta è troppo grande. Il nome del bind non è vuoto. Aiuto!
NetSide,

2
Grazie signore, questo è stato utile subito! L'impostazione di un nuovo valore per maxReceivedMessageSize richiede lo stesso valore per maxBufferSize.
Diligente

1
@Sandepku se si utilizza webhttpbinding per REST, potrebbe essere necessario rendere il nome di associazione in <binding> uguale a bindingConfigurazione in <endpoint>
smoothumut

55

Stavo riscontrando lo stesso problema con IIS 7.5 con un servizio REST WCF. Tentativo di caricare tramite POST qualsiasi file superiore a 65k e restituirebbe l'errore 413 "Richiesta entità troppo grande".

La prima cosa che devi capire è che tipo di associazione hai configurato in web.config. Ecco un ottimo articolo ...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Se si dispone di un servizio REST, è necessario configurarlo come "webHttpBinding". Ecco la soluzione:

<system.serviceModel>

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

2
Grazie, questo ha funzionato per me utilizzando IIS 7.5 con un servizio REST WCF. In effetti, ho dovuto solo modificare l'attributo maxReceivedMessageSize.
Alex, il

Ho avuto maxReceivedMessageSize, maxBufferSize ha fatto il trucco, maxBufferPoolSize mostrato come un attributo non valido.
JabberwockyDecompiler

4
assicurarsi di definire il nome del binding e renderlo uguale a bindingConfiguration sull'endpoint. Esempio: <binding name = "restLargeBinding" maxBufferPoolSize = ..........>. E nella configurazione del servizio; <endpoint address = "" binding = "webHttpBinding" bindingConfiguration = "restLargeBinding" .......
smoothumut

2
funziona benissimo, anche se l'impostazione di transferMode = "Streamed" mi ha dato una cattiva richiesta, ho dovuto rimuovere quella
WtFudgE

1
@smoothumut So che è vecchio, ma bindingConfiguration = "restLargeBinding" ha fatto il trucco per me! A proposito sto usando il servizio wcf self hosted.
ramires.cabral,

26

Ho avuto lo stesso problema e impostandolo uploadReadAheadSizerisolto:

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

"Il valore deve essere compreso tra 0 e 2147483647."

È facilmente impostabile in applicationHost.config-fle se non vuoi fare una cosa cmd.

Si trova in WindowsFOLDER\System32\inetsrv\config(server 2008).

È necessario aprirlo con il blocco note. Eseguire prima un backup del file.

Secondo i commenti in configurazione, il modo consigliato per sbloccare le sezioni è utilizzare un tag di posizione:

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

Quindi puoi scrivere in fondo (poiché non esiste prima). Scrivo iomaxvalue qui - scrivi il tuo valore se vuoi.

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

Se lo hai messo per ultimo prima, </configuration>ad esempio, sai dove lo hai.

Spero che risolva i tuoi problemi. È stato un problema ambientale SSL per me, in cui troppi post hanno bloccato l'applicazione, generando un errore (413) Entità richiesta troppo grande .


1
Avendo già impostato maxReceivedMessageSizesu int.MaxValue, questo ha funzionato. Mi chiedo se ci siano problemi importanti nell'impostare questa opzione su int.MaxValue?
Langdon,

2
Qualcuno potrebbe sapere se uploadReadAheadSize è rilevante anche per i servizi WCF self-hosted, non in esecuzione tramite IIS? cioè questo è anche un problema relativo a Windows Server in generale?
antscode

@antscode Ho un API ospitato da solo e ho lo stesso problema - l'hai risolto con il tuo servizio di self hosting?
Trevor Daniel,

18

Stavo ricevendo questo messaggio di errore, anche se avevo le maximpostazioni impostate nell'associazione del mio file di configurazione del servizio WCF:

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

Sembrava che queste impostazioni di associazione non fossero state applicate, quindi il seguente messaggio di errore:

IIS7 - (413) Entità richiesta troppo grande durante la connessione al servizio.

.

Il problema

Mi sono reso conto che l' name=""attributo all'interno del <service>tag del nonweb.config è un campo di testo libero, come pensavo fosse. È il nome completo di un'esecuzione di un contratto di assistenza come indicato in questa pagina di documentazione .

Se ciò non corrisponde, le impostazioni di associazione non verranno applicate!

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

Spero che risparmi un po 'di dolore a qualcuno ...


1
Grazie per aver aggiunto questa soluzione! Indirettamente risolto il mio problema in quanto il mio nome del contratto è cambiato in sviluppo ma il cambiamento non è stato distribuito correttamente alla produzione. Il controllo di queste impostazioni ha risolto i miei errori (413) Entità richiesta troppo grandi dovuti all'utilizzo delle impostazioni predefinite della dimensione del messaggio.
Doug Knudsen,

Sono davvero contento che questo abbia aiutato qualcuno. Ho trascorso un bel po 'di tempo su questo, quindi ho sperato che avrebbe reso la giornata di qualcuno meno dolorosa.
Luca,

9

Se stai riscontrando questo problema nonostante provi tutte le soluzioni in questo thread e ti stai connettendo al servizio tramite SSL (ad esempio https), questo potrebbe aiutare:

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

Riassumendo (nel caso in cui il collegamento scompaia in futuro), se le tue richieste sono sufficientemente grandi, la negoziazione del certificato tra il client e il servizio fallirà in modo casuale. Per evitare che ciò accada, è necessario abilitare una determinata impostazione sui collegamenti SSL. Dal tuo server IIS, ecco i passaggi che devi eseguire:

  1. Via cmd o PowerShell, eseguire netsh http show sslcert. Questo ti darà la tua configurazione attuale. Ti consigliamo di salvarlo in qualche modo in modo da poterlo fare nuovamente riferimento in seguito.
  2. Si noti che "Negozia certificato client" è disabilitato. Questa è l'impostazione del problema; i seguenti passaggi dimostreranno come abilitarlo.
  3. Sfortunatamente non c'è modo di cambiare i binding esistenti; dovrai eliminarlo e aggiungerlo di nuovo. Esegui netsh http delete sslcert <ipaddress>:<port>dove si <ipaddress>:<port>trova l'IP: porta mostrata nella configurazione salvata in precedenza.
  4. Ora puoi aggiungere nuovamente l'associazione. Puoi visualizzare i parametri validi per netsh http add sslcert qui (MSDN) ma nella maggior parte dei casi il tuo comando sarà simile al seguente:

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

Se disponi di più collegamenti SSL, ripeterai la procedura per ciascuno di essi. Spero che questo aiuti a salvare qualcun altro le ore e le ore di mal di testa che questo problema mi ha causato.

EDIT: Nella mia esperienza, in realtà non è possibile eseguire direttamente il netsh http add sslcertcomando dalla riga di comando. Dovrai prima inserire il prompt di netsh digitando netshe quindi emettere il tuo comando come http add sslcert ipport=...per farlo funzionare.


Grazie per il post, ci ha aiutato a isolare il problema per noi, disattivando SSL si rimuove l'errore WCF. Sfortunatamente la negoziazione clientcert non ha modificato i nostri risultati in modo da funzionare su SSL. In cerca di altri bit da attivare :-(
Jafin

8

Questo mi ha aiutato a risolvere il problema (una riga - divisa per leggibilità / capacità di copia):

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

stai ospitando il tuo WCF in ambiente SharePoint? e hai dovuto riavviare IIS dopo aver applicato le modifiche?
theITvideos,

2

Per me, impostare il uploadReadAheadSize di int.MaxValue ha anche risolto il problema, dopo aver aumentato anche i limiti dell'associazione WCF.

Sembra che, quando si utilizza SSL, viene precaricato l'intero corpo dell'entità richiesta, per cui viene utilizzata questa proprietà della metabase.

Per maggiori informazioni, vedi:

La pagina non è stata visualizzata perché l'entità richiesta è troppo grande. IIS7


1
Le tue scoperte su SSL e 'uploadReadAheadSize' sono ottime! .. Ma non raccomando di impostarlo sul valore massimo
Learner

1

Per chiunque sia mai alla ricerca di un errore IIS WCF 413: Richiedi entità di grandi dimensioni e utilizzando un servizio WCF in Sharepoint, queste sono le informazioni per te. Le impostazioni nell'host dell'applicazione e in web.config suggerite in altri siti / post non funzionano in SharePoint se si utilizza MultipleBaseAddressBasicHttpBindingServiceHostFactory. È possibile utilizzare SP Powershell per ottenere il servizio SPWebService.Content, creare un nuovo oggetto SPWcvSettings e aggiornare le impostazioni come sopra per il proprio servizio (non esistono). Ricorda di utilizzare solo il nome del servizio (ad es. [Yourservice.svc]) durante la creazione e l'aggiunta delle impostazioni. Vedi questo sito per maggiori informazioni https://robertsep.wordpress.com/2010/12/21/set-ma maximum- upload- filesize- sharepoint- wcf- service


1

Nel mio caso ho dovuto aumentare la "Dimensione massima del messaggio ricevuto" della posizione di ricezione in BizTalk. Anche questo ha un valore predefinito di 64 KB e quindi ogni messaggio è stato rimbalzato da BizTAlk indipendentemente da ciò che ho configurato nel mio web.config


1

Sono stato in grado di risolvere questo problema eseguendo una chiamata fittizia (ad es. IsAlive che restituisce true) appena prima della richiesta con contenuti di grandi dimensioni sullo stesso canale / client wcf. Apparentemente la negoziazione SSL viene effettuata alla prima chiamata. Quindi non è necessario aumentare Uploadreadaheadsize.


0

per problema il server remoto ha restituito una risposta imprevista: (413) Entità richiesta troppo grande su WCF con Resful

per favore vedi la mia spiegazione della configurazione

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

Nel mio caso, ho visualizzato questo messaggio di errore perché sono stato modificato lo spazio dei nomi del servizio e il tag dei servizi è stato puntato sullo spazio dei nomi più vecchio. Ho aggiornato lo spazio dei nomi e l'errore scompare:

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

0

Si è verificato un errore simile su IIS Express con Visual Studio 2017.

Errore HTTP 413.0 - Entità richiesta troppo grande

La pagina non è stata visualizzata perché l'entità richiesta è troppo grande.

Cause più probabili:

  • Il server Web si rifiuta di servire la richiesta perché l'entità della richiesta è troppo grande.

  • Il server Web non può soddisfare la richiesta perché sta tentando di negoziare un certificato client ma l'entità della richiesta è troppo grande.

  • L'URL della richiesta o il mapping fisico all'URL (ovvero il percorso del file system fisico al contenuto dell'URL) è troppo lungo.

Cose che puoi provare:

  • Verifica che la richiesta sia valida.

  • Se si utilizzano certificati client, provare:

    • Aumento di system.webServer/serverRuntime@uploadReadAheadSize

    • Configura il tuo endpoint SSL per negoziare i certificati client come parte dell'handshake SSL iniziale. (netsh http add sslcert ... clientcertnegotiation = abilita) .vs \ config \ applicationhost.config

Risolvilo modificando \.vs\config\applicationhost.config. Passa serverRuntimeda Denyin Allowquesto modo:

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

Se questo valore non viene modificato, verrà visualizzato un errore come questo quando si imposta uploadReadAheadSize:

Errore HTTP 500.19 - Errore interno del server

Non è possibile accedere alla pagina richiesta perché i relativi dati di configurazione per la pagina non sono validi.

Questa sezione di configurazione non può essere utilizzata in questo percorso. Ciò accade quando la sezione è bloccata a livello padre. Il blocco è di default (overrideModeDefault = "Deny") o impostato esplicitamente da un tag di posizione con overrideMode = "Deny" o l'eredità allowOverride = "false".

Quindi modifica Web.configcon i seguenti valori:

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

Se voti in basso, ti preghiamo di dire perché. Altrimenti è molto difficile migliorare le risposte.
Ogglas,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.