(413) Entidade de solicitação muito grande | uploadReadAheadSize

136

Eu escrevi um serviço WCF com o .NET 4.0, hospedado no meu sistema Windows 7 x64Ultimate com o IIS 7.5. Um dos métodos de serviço tem um 'objeto' como argumento e estou tentando enviar um byte [] que contém uma imagem. Contanto que o tamanho do arquivo desta imagem seja menor que aprox. 48KB, tudo vai bem. Mas se estou tentando fazer upload de uma foto maior, o serviço WCF retorna um erro: (413) Request Entity Too Large. é claro que passei 3 horas pesquisando a mensagem de erro no Google e todos os tópicos que vi sobre esse assunto sugerem aumentar a propriedade 'uploadReadAheadSize'. Então, o que eu fiz foi usar os seguintes comandos (10485760 = 10MB):

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

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

Também usei o Gerenciador do IIS para definir o valor abrindo o site e indo para o "Editor de Configuração" em Gerenciamento. Infelizmente ainda estou recebendo o erro Solicitar entidade muito grande e está ficando realmente frustrante!

Alguém sabe o que mais eu posso tentar corrigir esse erro?

kipusoep
fonte
6
10485760 = 10 MB, não 1MB
Shaun Rowan

Respostas:

206

Isso não é problema do IIS, mas o problema do WCF. Por padrão, o WCF limita as mensagens a 65 KB para evitar ataques de negação de serviço com mensagens grandes. Além disso, se você não usar o MTOM, ele enviará o byte [] para a string codificada em base64 (aumento de 33% no tamanho) => 48KB * 1,33 = 64KB

Para resolver esse problema, você deve reconfigurar seu serviço para aceitar mensagens maiores. Esse problema anteriormente disparava o erro 400 Bad Request, mas na versão mais recente o WCF começou a usar 413, que é o código de status correto para esse tipo de erro.

Você precisa definir maxReceivedMessageSizesua ligação. Você também pode precisar definir readerQuotas.

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding maxReceivedMessageSize="10485760">
        <readerQuotas ... />
      </binding>
    </basicHttpBinding>
  </bindings>  
</system.serviceModel>
Ladislav Mrnka
fonte
8
Tenho posto o maxRecievedMessageSize ao valor acima, mas eu ainda obter o mesmo erro .. Request Entity é muito grande ..
Sandepku
11
@ Sandepku- Apenas por precaução ... eu tive esse mesmo problema por muito tempo e percebi que havia nomeado o nome de ligação incorretamente, então o WCF estava usando os valores padrão em vez dos meus valores de configuração e estava me fornecendo exatamente mesmo erro.
Adrian Carr
1
Eu configurei o maxRecievedMessageSize para o valor acima, mas ainda assim recebo o mesmo erro. A entidade de solicitação é muito grande. O nome da ligação não está vazio. Socorro!
NetSide
2
Obrigado senhor, isso foi útil imediatamente! A configuração de um novo valor para maxReceivedMessageSize requer que o mesmo valor seja definido para maxBufferSize.
precisa
1
@Sandepku se você estiver usando WebHttpBinding para descanso, então você pode precisar fazer nome obrigatório em <binding> igual a bindingConfiguration em <endpoint>
smoothumut
55

Eu estava tendo o mesmo problema com o IIS 7.5 com um serviço REST WCF. Tentando enviar via POST qualquer arquivo acima de 65k e retornaria o Erro 413 "Solicitar entidade muito grande".

A primeira coisa que você precisa entender é que tipo de ligação você configurou no web.config. Aqui está um ótimo artigo ...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Se você tiver um serviço REST, precisará configurá-lo como "webHttpBinding". Aqui está a correção:

<system.serviceModel>

<bindings>
   <webHttpBinding>
    <binding 
      maxBufferPoolSize="2147483647" 
      maxReceivedMessageSize="2147483647" 
      maxBufferSize="2147483647" transferMode="Streamed">
    </binding>  
   </webHttpBinding>
</bindings>
Robert Barrueco
fonte
2
Obrigado, isso funcionou para mim usando o IIS 7.5 com um serviço WCF REST. Na verdade, eu só precisei modificar o atributo maxReceivedMessageSize.
Alex Yuly 27/10/14
Eu tive o maxReceivedMessageSize, o maxBufferSize fez o truque, maxBufferPoolSize mostrado como um atributo inválido.
precisa
4
defina o nome da ligação e iguale ao bindingConfiguration no nó de extremidade. Ex: <nome da ligação = "restLargeBinding" maxBufferPoolSize = ..........>. E na configuração de serviço; <endpoint address = "" binding = "webHttpBinding" bindingConfiguration = "restLargeBinding" .......
smoothumut
2
funciona muito bem, embora definindo a transferMode = "Streamed" me deu uma má pedido, teve de retirar aquele
WtFudgE
1
@smoothumut Eu sei que é velho, mas o bindingConfiguration = "restLargeBinding" fez o truque para mim! A propósito, eu estou usando o serviço wcf auto hospedado.
Ramires.cabral
26

Eu tive o mesmo problema e defini- uploadReadAheadSizelo resolvi:

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

"O valor deve estar entre 0 e 2147483647."

É fácil configurá-lo no applicationHost.config-fle se você não quiser fazer uma coisa de cmd.

Está localizado em WindowsFOLDER\System32\inetsrv\config(servidor 2008).

Você deve abri-lo com o bloco de notas. Faça um backup do arquivo primeiro.

De acordo com os comentários em config, a maneira recomendada de desbloquear seções é usando uma tag de localização:

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

Então você pode escrever na parte inferior (já que ela não existe antes). Eu escrevo maxvalueaqui - escreva seu próprio valor, se quiser.

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

Se você colocar o último antes, </configuration>por exemplo, você sabe onde está.

Espero que resolva seus problemas. Foi um problema de sobrecarga de SSL para mim, onde muita postagem congelou o aplicativo, gerando um erro (413) Solicitar entidade muito grande .

Tom P
fonte
1
Já definido maxReceivedMessageSizecomo int.MaxValue, isso funcionou. Gostaria de saber se há alguma grande preocupação em definir essa opção para int.MaxValue também?
Langdon
2
Alguém saberia se uploadReadAheadSize também é relevante para os serviços WCF auto-hospedados, que não estão sendo executados via IIS? ou seja, isso também é um problema relacionado ao Windows Server em geral?
Antscode
@antscode Eu tenho uma API hospedada e sofro o mesmo problema - você resolveu com o serviço de hospedagem hospedada?
Trevor Daniel
17

Eu estava recebendo essa mensagem de erro, mesmo tendo as maxconfigurações definidas na ligação do meu arquivo de configuração do serviço 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>

Parecia que essas configurações de ligação não estavam sendo aplicadas, portanto, a seguinte mensagem de erro:

IIS7 - (413) Entidade de solicitação muito grande ao se conectar ao serviço.

.

O problema

Percebi que o name=""atributo dentro da <service>tag do nãoweb.config é um campo de texto livre, como eu pensava. É o nome completo de uma implementação de um contrato de serviço, conforme mencionado nesta página de documentação .

Se isso não corresponder, as configurações de encadernação não serão aplicadas!

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

Espero que isso poupe a alguém uma dor ...

Lucas
fonte
1
Obrigado por adicionar esta solução! Resolvi indiretamente meu problema, pois meu nome de contrato mudou em dev, mas a alteração não foi implantada na produção corretamente. A verificação dessas configurações resolveu meus erros (413) de entidade de solicitação muito grandes devido ao uso das configurações padrão de tamanho da mensagem.
Doug Knudsen
Estou muito feliz que isso tenha ajudado alguém. Passei um bom tempo nisso, então esperava que isso tornasse o dia de alguém menos doloroso.
Lucas
9

Se você está enfrentando esse problema, apesar de tentar todas as soluções neste segmento, e está se conectando ao serviço via SSL (por exemplo, https), isso pode ajudar:

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

Para resumir (caso o link acabe no futuro), se suas solicitações forem grandes o suficiente, a negociação do certificado entre o cliente e o serviço falhará aleatoriamente. Para impedir que isso aconteça, será necessário ativar uma certa configuração em suas ligações SSL. No servidor IIS, eis as etapas que você precisará executar:

  1. Via cmd ou powershell, execute netsh http show sslcert. Isso fornecerá sua configuração atual. Você vai querer salvá-lo de alguma forma para poder referenciá-lo novamente mais tarde.
  2. Você deve observar que "Negociar certificado de cliente" está desativado. Esta é a configuração do problema; as etapas a seguir demonstrarão como ativá-lo.
  3. Infelizmente, não há como alterar as ligações existentes; você terá que excluí-lo e adicioná-lo novamente. Execute netsh http delete sslcert <ipaddress>:<port>onde <ipaddress>:<port>está a porta IP: mostrada na configuração que você salvou anteriormente.
  4. Agora você pode adicionar novamente a ligação. Você pode visualizar os parâmetros válidos para netsh http add sslcert aqui (MSDN), mas na maioria dos casos, seu comando será semelhante a este:

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 você tiver várias ligações SSL, repetirá o processo para cada uma delas. Espero que isso ajude a salvar outra pessoa das horas e horas de dor de cabeça que esse problema me causou.

Edição: Na minha experiência, você não pode realmente executar o netsh http add sslcertcomando diretamente da linha de comando. Você precisará inserir o prompt netsh primeiro digitando netshe, em seguida, emitir seu comando como http add sslcert ipport=...para que ele funcione.

oconnerj
fonte
Obrigado pela postagem, ele ajudou a isolar o problema para nós. Desativar o SSL remove o erro do WCF. Infelizmente, a negociação de certificação do cliente não alterou nosso resultado para funcionar com SSL. Stil procurando outros bits para alternar :-(
Jafin
8

Isso me ajudou a resolver o problema (uma linha - divisão por legibilidade / capacidade de cópia):

C:\Windows\System32\inetsrv\appcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost
Anas
fonte
você está hospedando seu WCF no ambiente do SharePoint? e você teve que reiniciar o IIS após aplicar as alterações?
theITvideos 23/11
2

Para mim, definir o valor uploadReadAheadSizepara int.MaxValue também corrigiu o problema, depois de aumentar os limites na ligação do WCF.

Parece que, ao usar SSL, todo o corpo da entidade da solicitação é pré-carregado, para o qual essa propriedade da metabase é usada.

Para mais informações, consulte:

A página não foi exibida porque a entidade de solicitação é muito grande. iis7

inverter
fonte
1
Sua descoberta sobre SSL e 'uploadReadAheadSize' é muito boa! .. Mas eu não recomendo para defini-lo como valor máximo embora
Learner
1

Para qualquer outra pessoa que esteja procurando por um erro 413 do WCF do IIS: solicite uma entidade grande e use um serviço WCF no Sharepoint, essas são as informações para você. As configurações no host do aplicativo e no web.config sugeridas em outros sites / postagens não funcionam no SharePoint se você usar o MultipleBaseAddressBasicHttpBindingServiceHostFactory. Você pode usar o SP Powershell para obter o serviço SPWebService.Content, criar um novo objeto SPWcvSettings e atualizar as configurações conforme acima para o seu serviço (elas não existirão). Lembre-se de usar apenas o nome do serviço (por exemplo, [YOURService.svc]) ao criar e adicionar as configurações. Consulte este site para obter mais informações https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service

Riccardo Gozzi
fonte
1

No meu caso, tive que aumentar o "Tamanho máximo da mensagem recebida" do Local de recebimento no BizTalk. Isso também tem um valor padrão de 64K e, portanto, todas as mensagens foram devolvidas pelo BizTAlk, independentemente do que eu configurei no meu web.config

Han Evers
fonte
1

Consegui resolver isso executando uma chamada fictícia (por exemplo, IsAlive retornando true) pouco antes da solicitação com grande conteúdo no mesmo canal / cliente wcf. Aparentemente, a negociação de SSL é feita na primeira chamada. Portanto, não há necessidade de aumentar o tamanho do tamanho da fonte.

rekna
fonte
0

para emitir, o servidor remoto retornou uma resposta inesperada: (413) Solicitar entidade muito grande no WCF com resful

veja minha configuração de explicação

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

No meu caso, estava recebendo essa mensagem de erro porque havia alterado o espaço para nome do serviço e a tag services estava apontada para o espaço para nome mais antigo. Atualizei o espaço para nome e o erro desaparece:

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

Erro semelhante no IIS Express com o Visual Studio 2017.

Erro HTTP 413.0 - Entidade de solicitação muito grande

A página não foi exibida porque a entidade de solicitação é muito grande.

Causas mais prováveis:

  • O servidor da Web está se recusando a atender a solicitação porque a entidade da solicitação é muito grande.

  • O servidor da Web não pode atender à solicitação porque está tentando negociar um certificado de cliente, mas a entidade da solicitação é muito grande.

  • O URL da solicitação ou o mapeamento físico para o URL (ou seja, o caminho do sistema de arquivos físico para o conteúdo do URL) é muito longo.

Coisas que você pode tentar:

  • Verifique se a solicitação é válida.

  • Se estiver usando certificados de cliente, tente:

    • Aumentando system.webServer/serverRuntime@uploadReadAheadSize

    • Configure seu terminal SSL para negociar certificados de cliente como parte do handshake SSL inicial. (netsh http adiciona sslcert ... clientcertnegotiation = enable) .vs \ config \ applicationhost.config

Resolva isso editando \.vs\config\applicationhost.config. Alterne serverRuntimede Denypara Allowassim:

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

Se esse valor não for editado, você receberá um erro como este ao definir uploadReadAheadSize:

Erro HTTP 500.19 - Erro interno do servidor

A página solicitada não pode ser acessada porque os dados de configuração relacionados para a página são inválidos.

Esta seção de configuração não pode ser usada neste caminho. Isso acontece quando a seção está bloqueada no nível pai. O bloqueio é por padrão (overrideModeDefault = "Negar") ou definido explicitamente por uma tag de local com overrideMode = "Negar" ou pelo legado allowOverride = "false".

Em seguida, edite Web.configcom os seguintes valores:

<system.webServer>
  <serverRuntime uploadReadAheadSize="10485760" />
...
Ogglas
fonte
Se você votar, diga o porquê. Muito difícil melhorar as respostas caso contrário.
Ogglas