Estoy escribiendo un controlador Spring que maneja la solicitud HTTP PUT del cliente y genera una URL prefirmada de S3 y emite un código de estado HTTP 307 (redireccionamiento temporal). Básicamente, estoy autenticando al cliente y, si tiene éxito, le pido que escriba en una carpeta s3. El cliente puede escribir en la ubicación de URL firmada.
Ahora mi preocupación es que el cliente tendrá que cargar dos veces. Una vez a mi servidor de aplicaciones y luego a s3, por lo que la operación llevará el doble de tiempo.
¿Es correcto mi entendimiento? ¿El cliente realmente escribe 2 en este caso? ¿O es el cliente lo suficientemente inteligente y solo empuja la parte de la carga útil primero y, si tiene éxito, empuja la carga útil completa?
Leí sobre el código de estado HTTP 100, pero parece que el servidor de aplicaciones/Tomcat ya lo emite y no está bajo mi control.
Aquí está mi controlador de resorte
@RequestMapping("/upload") public ResponseEntity<Void> execute(HttpServletRequest request) throws IOException, ServletException { HttpHeaders headers = new HttpHeaders(); String redirectUrl = getRedirectUrl(requestURI, request.getMethod()); headers.setLocation(new URI(redirectUrl)); ResponseEntity<Void> redirectEntity = new ResponseEntity<Void>(null,headers,HttpStatus.TEMPORARY_REDIRECT); return redirectEntity; }¿Cómo puedo evitar que Clint cargue toda la carga útil en mi servidor de aplicaciones?
Entonces mi entendimiento es correcto?
La respuesta es SÍ. El servidor enviará la respuesta de la solicitud PUT después de leer la solicitud completa, incluido el cuerpo. cuando su cliente repita la solicitud, en respuesta 307 ( Redirección temporal ), será como una nueva solicitud http.
También se debe considerar un punto importante sobre el uso del código de respuesta 307 de la especificación (ver a continuación) para este enfoque.
Si el código de estado 307 se recibe en respuesta a una solicitud que no sea
que GET o HEAD, el agente de usuario NO DEBE redirigir automáticamente el
solicitud a menos que pueda ser confirmada por el usuario, ya que esto podría
cambiar las condiciones bajo las cuales se emitió la solicitud.
En punto
How can i prevent client from uploading the entire payload to my app server? Puede cargar a s3 en segundo plano desde su controlador y devolver el punto de respuesta de redireccionamiento (¿301?) a una URL que devolverá el estado de la solicitud de carga.
Así no es como funciona HTTP, HTTP no tiene ningún mecanismo para detener la carga de un archivo que no sea cerrar la conexión, pero si cierra la conexión no puede devolver la información de redirección.
Si desea que el cliente se cargue directamente en S3, deberá hacerlo en dos pasos.
Haga que el cliente solicite la URL para la transferencia de archivos, luego pídale que inicie la transferencia con la URL deseada.