traducir too the solucion solicitud servidor salida returned remoto remote página porque para mostró large larga información español error entidad depuración demasiado consola comprueba wcf iis

wcf - too - (413) Entidad de solicitud demasiado grande | uploadReadAheadSize



status 413 (10)

Escribí un servicio WCF con .NET 4.0, alojado en mi sistema Windows 7 x64 Ultimate 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 intento cargar una imagen más grande, el servicio WCF devuelve un error: (413) Request Entity Too Large. Así que, por supuesto, he pasado 3 horas buscando en Google el mensaje de error y cada tema que he visto sobre este tema sugiere subir la propiedad ''uploadReadAheadSize''. Entonces, lo que hice fue 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 utilicé el Administrador de IIS para establecer el valor abriendo el sitio y yendo a "Editor de configuración" en Gestión. Desafortunadamente, sigo recibiendo el error de Request Entity Too Large y se está volviendo realmente frustrante.

Entonces, ¿alguien sabe qué más puedo intentar para solucionar este error?

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 64 KB, por lo que Biztalk devolvió cada mensaje independientemente de lo que configuré en mi web.config

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

Para resolver este problema, debe volver a configurar su servicio para aceptar mensajes más grandes. Este problema anteriormente generó 400 errores 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.

maxReceivedMessageSize establecer maxReceivedMessageSize en su enlace. También puede necesitar establecer readerQuotas .

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

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ía el error 413 "Entidad de solicitud demasiado grande".

Lo primero que debe entender 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>

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

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

Para cualquier otra persona que busque un error IIS WCF 413: solicitar entidad a gran tamaño y usar un servicio WCF en Sharepoint, esta es la información para usted. Las configuraciones en el host de aplicaciones y web.config sugeridas en otros sitios / publicaciones no funcionan 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 para su servicio anterior (no existirán). Recuerde utilizar 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

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

Recibí este mensaje de error, aunque tenía la configuración max establecida en el 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 atributo name="" dentro de la etiqueta <service> de web.config no 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, ¡la configuración de enlace no se aplicará!

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

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 muera en el futuro), si sus solicitudes son lo suficientemente grandes, la negociación del certificado entre el cliente y el servicio fallará aleatoriamente. Para evitar que esto suceda, deberá habilitar una determinada configuración en sus enlaces SSL. Desde su servidor IIS, estos son los pasos que debe seguir:

  1. A través de cmd o powershell, ejecute netsh http show sslcert . Esto le dará su configuración actual. Querrá guardar esto de alguna manera para poder consultarlo más tarde.
  2. Debería observar que "Negotiate Client Certificate" está deshabilitado. Esta es la configuración del problema; los siguientes pasos demostrarán cómo habilitarlo.
  3. Lamentablemente, no hay forma de cambiar las vinculaciones existentes; Tendrás que eliminarlo y volver a agregarlo. Ejecute netsh http delete sslcert <ipaddress>:<port> donde <ipaddress>:<port> es el IP: puerto que se muestra en la configuración que guardó anteriormente.
  4. Ahora puedes volver a agregar el enlace. Puede ver los parámetros válidos para 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 múltiples enlaces SSL, repetirá el proceso para cada uno de ellos. Espero que esto ayude a salvar a otra persona las horas y horas de dolor de cabeza que me causó este problema.

EDITAR: En mi experiencia, no se puede ejecutar el comando netsh http add sslcert directamente desde la línea de comando. Necesitará ingresar primero al indicador netsh escribiendo netsh y luego emita su comando como http add sslcert ipport=... para que funcione.

Tuve el mismo problema y la configuración de uploadReadAheadSize resolvió:

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

"El valor debe estar entre 0 y 2147483647".

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

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

Debes abrirlo con el bloc de notas. Haz una copia de seguridad del archivo primero.

De acuerdo con los comentarios en config, la forma recomendada para 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>"

Entonces puedes escribir en la parte inferior (ya que no existe antes). Escribo maxvalue aquí - escribe tu propio valor si quieres.

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

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

Espero que resuelva tus problemas. Fue un problema de sobrecarga de SSL para mí, donde demasiada publicación congelaba la aplicación, lo que generaba un error (413) de entidad de solicitud demasiado grande .