0
337
Visualizações¿Cómo se envían los encabezados de respuesta al cliente cuando la canalización de middleware no ha terminado?
Estoy leyendo un libro que muestra que ExceptionHandlerMiddleware vuelve a ejecutar una canalización de middleware para generar la respuesta enviada al usuario como (use app.UseExceptionHandler("/Error"); ):
Y el autor dice:
Volver a ejecutar la tubería de middleware es una excelente manera de mantener la coherencia en su aplicación web para las páginas de error, pero hay algunos errores que debe tener en cuenta. En primer lugar, el middleware solo puede modificar una respuesta generada más adelante en la canalización si la respuesta aún no se ha enviado al cliente. Esto puede ser un problema si, por ejemplo, se produce un error mientras ASP.NET Core envía un archivo estático a un cliente. En ese caso, donde los bytes ya han comenzado a enviarse, el middleware de manejo de errores no podrá ejecutarse, ya que no puede restablecer la respuesta.
Estoy confundido acerca de la parte "los bytes ya comenzaron a enviarse, el middleware de manejo de errores no podrá ejecutarse".
Digamos que construimos la canalización como:
y digamos que un cliente está solicitando un archivo css, lo que entiendo sobre el middleware de archivos estáticos es que este middleware lee el archivo correspondiente en la carpeta wwwroot y escribe el contenido del archivo css en HttpContext.Response , por lo que incluso se produce un error y un excepción lanzada a la mitad, solo significa que HttpContext.Response (cuando está en el middleware de archivo estático) está incompleto, y ExceptionHandlerMiddleware detectará esta excepción ya que ExceptionHandlerMiddleware debe usar un intento y captura para esperar la tarea, por lo que cuando ExceptionHandlerMiddleware detecta que se lanzó una excepción desde el middleware debajo de él, entonces ExceptionHandlerMiddleware puede volver a ejecutar la canalización con una nueva ruta /Error .
Entonces, ¿cómo envía el middleware de archivos estáticos la respuesta al cliente antes de que el control recurra al ExceptionHandlerMiddleware? ¿No es que el trabajo del servidor web Kestrel o del proxy inverso es enviar la respuesta a los clientes?
1 Respostas
Responde à pergunta0
Hay algunos puntos que pueden ayudarte a obtener tu respuesta:
1- ASP.NET Core no almacena en búfer el cuerpo de respuesta HTTP . La primera vez que se escribe la respuesta:
- Los encabezados se envían junto con esa parte del cuerpo al cliente.
- Ya no es posible cambiar los encabezados de respuesta.
2- HasStarted es una propiedad en HTTPResponse que indica si se han enviado encabezados de respuesta al cliente.
3- Los componentes solo esperan ser llamados si pueden manejar y manipular la respuesta.
Entonces, poner los tres puntos juntos significa: Cuando el archivo estático comienza a enviarse, la propiedad HasStarted se establece en verdadero. Después de ese punto, no puede invocar next() (en el contexto de la solicitud actual) ya que la respuesta ya comenzó. Sin embargo, si usamos redirigir en lugar de volver a ejecutar, sería una solicitud diferente y podemos generar la respuesta deseada.