Ajustar la configuración de IIS para simplificar las cargas de clientes de Windows Server

Muchos sitios web utilizan un navegador web para permitir a los usuarios cargar contenido directamente, pero este enfoque carece de la interactividad entre el usuario y el servidor remoto, lo que hace que su interacción sea menos fácil. En primer lugar, básicamente no hay retroalimentación durante el proceso de carga y, a veces, la única retroalimentación que se obtiene después de una larga espera es un error molesto. Sin embargo, el uso de un navegador para cargar archivos sigue siendo un método ampliamente aceptado de transferencia de archivos. Porque los usuarios prefieren su simplicidad, en lugar del uso laborioso de las herramientas del Protocolo de transferencia de archivos (FTP). Aunque este método es ampliamente aceptado, no garantiza que no saldrá mal. Un problema confirmado de Microsoft IIS es que se produce un error de tiempo de espera al procesar un archivo de carga mayor a 48K. Algunas veces esto es solo un error de carga, pero otras veces hará que el navegador ingrese un ciclo infinito de intentos de reenviar datos constantemente. Porque para el navegador, no hay una respuesta estándar para esta situación en particular. El motivo de este bloqueo es que IIS utiliza una aplicación como ASP para manejar la carga de datos del cliente. Cuando el cliente comienza a enviar datos, IIS lee los primeros 48K de datos en el búfer y los pasa a la aplicación para su procesamiento. Cualquier información que exceda este 48 K estará en estado de espera hasta que la aplicación solicite una transferencia, generalmente a través de un comando como Request.BinaryRead (Request.TotalBytes). Si la aplicación no solicita, los datos están esperando una conexión. Este es un error típico de 413: la entidad de solicitud es demasiado grande. En general, una buena codificación de acuerdo con las reglas anteriores puede evitar este tipo de problemas, pero en algunos casos es posible que deba usar una configuración de propiedad específica. Por ejemplo, si la carga de uno de sus sitios es manejada por una extensión ISAPI de terceros, no sigue esta práctica, y se necesitan algunos ajustes para superar el límite de 48K. Esta restricción no es estática, está definida por un atributo de metadatos de IIS llamado UploadReadAheadSize. El valor predeterminado es 49152K y el máximo se puede establecer en 4 GB. Si lo necesita, puede configurar un sitio separado o configurar todo el servicio IIS. Esta puede no ser la única propiedad que necesita ser establecida. También es posible que deba modificar los valores de los atributos maxRequestLength (en IIS6) o maxAllowedContentLength (en IIS7 +) para permitir grandes cargas de datos, aunque sus valores predeterminados son más grandes. En algunos casos, puede ser útil establecer el valor de UploadReadAheadSize en cero. Esto obliga a IIS a transmitir el contenido enviado directamente a la aplicación de extensión ISAPI para procesar la solicitud. Este puede ser el primer método que vale la pena intentar resolver este problema, pero también debería notar los posibles efectos secundarios de cerrar la aplicación IIS (sin procesar el búfer de lectura anticipada). Finalmente, tenga en cuenta que aumentar el valor de UploadReadAheadSize producirá una superficie de ataque. Si este valor se establece alto y alguien quiere atacar su sistema cargando archivos para consumir ancho de banda, será fácil obtenerlos. Para evitar ataques, utilice un método que refleje el uso real del usuario e insista en usar la autenticación tanto como sea posible para garantizar que la identidad del usuario que carga la información sea confiable.