(413) Entidad de solicitud demasiado grande | uploadReadAheadSize


136

He escrito un servicio WCF con .NET 4.0, que está alojado en mi sistema Windows 7 x64Ultimate con IIS 7.5. Uno de los métodos de servicio tiene un 'objeto' como argumento y estoy tratando de enviar un byte [] que contiene una imagen. Siempre que el tamaño del archivo de esta imagen sea inferior a aprox. 48 KB, todo va bien. Pero si estoy tratando de subir una imagen más grande, el servicio WCF devuelve un error: (413) Request Entity Too Large. por supuesto, he pasado 3 horas buscando en Google el mensaje de error y cada tema que he visto sobre este tema sugiere que aparezca la propiedad 'uploadReadAheadSize'. Entonces, lo que he hecho es usar los siguientes comandos (10485760 = 10MB):

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

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

También he usado el Administrador de IIS para establecer el valor abriendo el sitio y yendo al "Editor de configuración" en Administración. Desafortunadamente, sigo recibiendo el error Solicitar entidad demasiado grande y se está volviendo muy frustrante.

Entonces, ¿alguien sabe qué más puedo tratar de corregir este error?


66
10485760 = 10MB, no 1MB
Shaun Rowan

Respuestas:


206

Ese no es un problema de IIS sino el problema de WCF. WCF limita de forma predeterminada los mensajes a 65 KB para evitar ataques de denegación de servicio con mensajes grandes. Además, si no utiliza MTOM, envía el byte [] a la cadena codificada en base64 (aumento del tamaño del 33%) => 48 KB * 1,33 = 64 KB

Para resolver este problema, debe volver a configurar su servicio para aceptar mensajes más grandes. Este problema disparó anteriormente 400 Error de solicitud incorrecta, pero en la versión más reciente, WCF comenzó a usar 413, que es el código de estado correcto para este tipo de error.

Necesita establecer maxReceivedMessageSizeen su encuadernación. También puede necesitar configurar readerQuotas.

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

8
yo he dado la maxRecievedMessageSize al valor anterior, pero todavía me sale el mismo error .. entidad de solicitud es demasiado grande ..
Sandepku

11
@ Sandepku- Por si acaso ... Tuve el mismo problema durante bastante tiempo, y luego me di cuenta de que había llamado mal el Nombre de enlace, por lo que WCF estaba usando los valores predeterminados en lugar de mis valores de configuración, y me estaba dando exactamente mismo error.
Adrian Carr

1
He configurado maxRecievedMessageSize en el valor anterior, pero sigo teniendo el mismo error. La entidad de solicitud es demasiado grande. El nombre del enlace no está vacío. ¡Ayuda!
NetSide

2
Gracias señor, esto fue útil de inmediato. Establecer un nuevo valor para maxReceivedMessageSize requiere que se establezca el mismo valor para maxBufferSize.
DiligentKarma

1
@Sandepku si está utilizando webhttpbinding para REST, entonces es posible que deba hacer que el nombre del enlace en <binding> sea igual a la configuración del enlace en <endpoint>
smoothumut el

55

Estaba teniendo el mismo problema con IIS 7.5 con un servicio WCF REST. Intentando cargar a través de POST cualquier archivo por encima de 65k y devolverá el Error 413 "Solicitar entidad demasiado grande".

Lo primero que debe comprender es qué tipo de enlace ha configurado en web.config. Aquí hay un gran artículo ...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Si tiene un servicio REST, debe configurarlo como "webHttpBinding". Aquí está la solución:

<system.serviceModel>

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

2
Gracias, esto funcionó para mí usando IIS 7.5 con un servicio WCF REST. De hecho, solo tuve que modificar el atributo maxReceivedMessageSize.
Alex Yuly

Tenía maxReceivedMessageSize, maxBufferSize hizo el truco, maxBufferPoolSize se mostró como un atributo no válido.
JabberwockyDecompiler

44
asegúrese de definir el nombre del enlace y hacerlo igual a la configuración del enlace en el punto final. Ej: <enlace nombre = "restLargeBinding" maxBufferPoolSize = ..........>. Y en configuración de servicio; <endpoint address = "" binding = "webHttpBinding" bindingConfiguration = "restLargeBinding" .......
smoothumut

2
funciona muy bien, aunque configurar el transferMode = "Streamed" me dio una mala solicitud, tuve que eliminarla
WtFudgE

1
@smoothumut Sé que es viejo, ¡pero el enlaceConfiguration = "restLargeBinding" me sirvió! Por cierto, estoy usando el servicio wcf alojado por mí mismo.
ramires.cabral

26

Tuve el mismo problema y la configuración lo uploadReadAheadSizeresolvió:

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

"El valor debe estar entre 0 y 2147483647."

Se configura fácilmente en applicationHost.config-fle si no desea hacer un cmd.

Está ubicado en WindowsFOLDER\System32\inetsrv\config(servidor 2008).

Debe abrirlo con el bloc de notas. Haga una copia de seguridad del archivo primero.

De acuerdo con los comentarios en la configuración, la forma recomendada de desbloquear secciones es mediante el uso de una etiqueta de ubicación:

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

Para que pueda escribir en la parte inferior (ya que no existe antes). Escribo maxvalueaquí, escribe tu propio valor si quieres.

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

Si lo pones antes, </configuration>por ejemplo, sabes dónde lo tienes.

Espero que eso resuelva tus problemas. Fue un problema de sobrecarga SSL para mí, donde demasiadas publicaciones congelaron la aplicación, generando un error (413) Solicitar entidad demasiado grande .


1
Habiendo establecido ya maxReceivedMessageSizeint.MaxValue, esto hizo el truco. Me pregunto si hay alguna preocupación importante con la configuración de esta opción en int.MaxValue también.
Langdon

2
¿Alguien sabe si uploadReadAheadSize también es relevante para los servicios WCF autohospedados, que no se ejecutan a través de IIS? es decir, ¿también es un problema relacionado con Windows Server en general?
antscode

@antscode Tengo una API alojada y tengo el mismo problema: ¿la resolvió con su servicio alojado?
Trevor Daniel

18

Recibí este mensaje de error, aunque tenía la maxconfiguración establecida dentro del enlace de mi archivo de configuración del servicio 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>

Parecía que estas configuraciones de enlace no se estaban aplicando, por lo tanto, el siguiente mensaje de error:

IIS7 - (413) Entidad de solicitud demasiado grande cuando se conecta al servicio.

.

El problema

Me di cuenta de que el name=""atributo dentro de la <service>etiqueta del noweb.config es un campo de texto libre, como pensé que era. Es el nombre completo de una implementación de un contrato de servicio como se menciona en esta página de documentación .

Si eso no coincide, ¡no se aplicará la configuración de enlace!

<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 eso le ahorre a alguien algo de dolor ...


1
¡Gracias por agregar esta solución! Indirectamente resolvió mi problema porque el nombre de mi contrato cambió en desarrollo pero el cambio no se implementó en producción correctamente. La comprobación de esta configuración resolvió mis errores (413) Solicitar entidad demasiado grandes debido al uso de la configuración predeterminada del tamaño del mensaje.
Doug Knudsen

Estoy realmente contento de que esto haya ayudado a alguien. Pasé un buen rato en esto, así que esperaba que hiciera el día de alguien menos doloroso.
Lucas

9

Si se encuentra con este problema a pesar de probar todas las soluciones en este hilo y se está conectando al servicio a través de SSL (por ejemplo, https), esto podría ayudar:

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

Para resumir (en caso de que el enlace falle en el futuro), si sus solicitudes son lo suficientemente grandes, la negociación del certificado entre el cliente y el servicio fallará al azar. Para evitar que esto suceda, deberá habilitar una determinada configuración en sus enlaces SSL. Desde su servidor IIS, estos son los pasos que deberá seguir:

  1. Vía cmd o powershell, ejecute netsh http show sslcert. Esto le dará su configuración actual. Querrá guardar esto de alguna manera para poder consultarlo nuevamente más tarde.
  2. Debería notar que "Negociar certificado de cliente" está desactivado. Esta es la configuración del problema; Los siguientes pasos demostrarán cómo habilitarlo.
  3. Lamentablemente, no hay forma de cambiar los enlaces existentes; deberás eliminarlo y volver a agregarlo. Ejecute netsh http delete sslcert <ipaddress>:<port>donde <ipaddress>:<port>está la IP: puerto que se muestra en la configuración que guardó anteriormente.
  4. Ahora puede volver a agregar el enlace. Puede ver los parámetros válidos netsh http add sslcert aquí (MSDN) pero en la mayoría de los casos su comando se verá así:

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

Si tiene varios enlaces SSL, repetirá el proceso para cada uno de ellos. Espero que esto ayude a salvar a alguien más las horas y las horas de dolor de cabeza que me causó este problema.

EDITAR: En mi experiencia, en realidad no puede ejecutar el netsh http add sslcertcomando desde la línea de comando directamente. Primero deberá ingresar el indicador de netsh escribiendo netshy luego emitir su comando como http add sslcert ipport=...para que funcione.


Gracias por la publicación, nos ayudó a aislar el problema, apagar SSL elimina el error WCF. Lamentablemente, la negociación con el cliente no cambió nuestro resultado para que funcione a través de SSL. Stil buscando otros bits para alternar :-(
Jafin

8

Esto me ayudó a resolver el problema (una línea, dividida para facilitar la lectura / capacidad de copia):

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

¿Aloja su WCF en el entorno de SharePoint? ¿Tuviste que reiniciar tu IIS después de aplicar los cambios?
theITvideos

2

Para mí, establecer el uploadReadAheadSizeint.MaxValue también solucionó el problema, después de aumentar también los límites en el enlace WCF.

Parece que, cuando se usa SSL, todo el cuerpo de la entidad de solicitud está precargado, para lo cual se utiliza esta propiedad de metabase.

Para más información, ver:

La página no se mostró porque la entidad de solicitud es demasiado grande. iis7


1
¡Su hallazgo sobre SSL y 'uploadReadAheadSize' es muy bueno! .. Pero no recomiendo que ponerlo en valor máximo, aunque
Estudiantes de

1

Para cualquier otra persona que esté buscando un error 413 WCF de IIS: Solicitar entidad a gran tamaño y usar un servicio WCF en Sharepoint, esta es la información para usted. La configuración en el host de la aplicación y web.config sugerida en otros sitios / publicaciones no funciona en SharePoint si se usa MultipleBaseAddressBasicHttpBindingServiceHostFactory. Puede usar SP Powershell para obtener el servicio SPWebService.Content, crear un nuevo objeto SPWcvSettings y actualizar la configuración como se indica arriba para su servicio (no existirán). Recuerde usar el nombre del servicio (por ejemplo, [yourservice.svc]) al crear y agregar la configuración. Consulte este sitio para obtener más información https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service


1

En mi caso, tuve que aumentar el "Tamaño máximo de mensaje recibido" de la Ubicación de recepción en BizTalk. Eso también tiene un valor predeterminado de 64K y, por lo tanto, BizTAlk rebotó todos los mensajes independientemente de lo que configuré en mi web.config


1

He podido resolver esto ejecutando una llamada ficticia (por ejemplo, IsAlive devuelve verdadero) justo antes de la solicitud con gran contenido en el mismo canal / cliente wcf. Aparentemente, la negociación de SSL se realiza en la primera llamada. Por lo tanto, no es necesario aumentar Uploadreadaheadsize.


0

Por problema, el servidor remoto devolvió una respuesta inesperada: (413) Solicitar entidad demasiado grande en WCF con Resful

por favor vea mi configuración de explicación

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

En mi caso, recibí este mensaje de error porque cambié el espacio de nombres del servicio y la etiqueta de servicios apuntaba al espacio de nombres anterior. Actualicé el espacio de nombres y el error desaparece:

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

0

Tengo un error similar en IIS Express con Visual Studio 2017.

Error HTTP 413.0: entidad de solicitud demasiado grande

La página no se mostró porque la entidad de solicitud es demasiado grande.

Las causas más probables:

  • El servidor web se niega a atender la solicitud porque la entidad de solicitud es demasiado grande.

  • El servidor web no puede atender la solicitud porque está tratando de negociar un certificado de cliente pero la entidad de solicitud es demasiado grande.

  • La URL de solicitud o la asignación física a la URL (es decir, la ruta del sistema de archivos físico al contenido de la URL) es demasiado larga.

Cosas que puedes probar:

  • Verifique que la solicitud sea válida.

  • Si usa certificados de cliente, intente:

    • Aumento de system.webServer/serverRuntime@uploadReadAheadSize

    • Configure su punto final SSL para negociar certificados de cliente como parte del protocolo de enlace SSL inicial. (netsh http add sslcert ... clientcertnegotiation = enable) .vs \ config \ applicationhost.config

Resuelve esto editando \.vs\config\applicationhost.config. Cambia serverRuntimede Denya me Allowgusta esto:

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

Si este valor no se edita, obtendrá un error como este al configurar uploadReadAheadSize:

Error HTTP 500.19 - Error interno del servidor

No se puede acceder a la página solicitada porque los datos de configuración relacionados para la página no son válidos.

Esta sección de configuración no se puede utilizar en esta ruta. Esto sucede cuando la sección está bloqueada en un nivel primario. El bloqueo se realiza de manera predeterminada (overrideModeDefault = "Deny"), o se establece explícitamente mediante una etiqueta de ubicación con overrideMode = "Deny" o el legado allowOverride = "false".

Luego edite Web.configcon los siguientes valores:

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

Si vota en contra, diga por qué. Muy difícil de mejorar las respuestas de lo contrario.
Ogglas
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.