http - redireccionar - Redireccionamiento antes de que se haya completado la carga POST

redireccionar https a https

Question

Tengo formulario con carga de archivos. Los archivos que se cargarán en realidad son fotos y videos, por lo que pueden ser bastante grandes. Tengo una lógica que se basa en los encabezados y el primer 1 KB puede determinar si el resto se procesará o se rechazará de inmediato. En el último caso, me gustaría redirigir al cliente a la página de error sin tener que esperar a que finalice la carga.

El caso es que el simple hecho de enviar una respuesta antes de que se complete la POST no parece funcionar. La redirección se ignora y si cierro la conexión, el navegador se queja con el error "Restablecimiento de la conexión por parte de un par" .

Entonces la pregunta es: ¿es incluso posible hacerlo en HTTP puro (sin JavaScript en el lado del cliente), y si es así, cómo?

Answer 1

1. usa la extensión PCEL uploadprogress si usas apache
2. cree un archivo para sondear el meta a través de Ajax, y devuelva verdadero o falso según su condición, también puede obtener el archivo nombre_temp y verificar el meta de 1 kb.
3. la llamada ajax debe vincularse con una función que utiliza encabezados HTML de meta-actualización para redirigir o permanecer hasta que se realicen las cargas.

Echa un vistazo a los ejemplos de uploadprogress.

Answer 2

Eche un vistazo al ticket # 10850 de django : "Imposible detener una carga de archivos de gran tamaño a mitad de la secuencia" . No resuelve el problema, pero al menos debería ayudarlo a entenderlo.

Answer 3

El protocolo HTTP / 1.1 permite esto, solo de una manera realmente extraña y desordenada. Debe aplicar el siguiente procedimiento de 3 pasos:

1. Inmediatamente (abruptamente) cierre la conexión, almacene un indicador del lado del servidor para la sesión del cliente
2. Use la bandera para detectar un intento de reenviar los mismos datos de formulario, la especificación recomienda que el cliente lo haga automáticamente
3. Enviar un estado de error con una redirección (como 302 Movido temporalmente)

Esto DEBERÍA funcionar porque como se describe a continuación, se espera que el cliente vuelva a intentar una conexión al menos una vez después de que se haya cortado inesperadamente. En el (los) intento (s) de reintento, se espera que solo envíe los encabezados, luego espere y observe una respuesta de error y aborte el envío del cuerpo si recibe uno.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

8.2.4 Comportamiento del cliente si el servidor cierra prematuramente la conexión

Si un cliente HTTP / 1.1 envía una solicitud que incluye un cuerpo de solicitud, pero que no incluye un campo de encabezado de solicitud de Expect con la expectativa de "continuar 100", y si el cliente no está conectado directamente a un servidor de origen HTTP / 1.1 , y si el cliente ve que la conexión se cierra antes de recibir cualquier estado del servidor, el cliente DEBE reintentar la solicitud. Si el cliente reintenta esta solicitud, PUEDE usar el siguiente algoritmo de "retroceso exponencial binario" para asegurarse de obtener una respuesta confiable:

 1. Initiate a new connection to the server
2. Transmit the request-headers
3. Initialize a variable R to the estimated round-trip time to the
server (e.g., based on the time it took to establish the
connection), or to a constant value of 5 seconds if the round-
trip time is not available.
4. Compute T = R * (2**N), where N is the number of previous
retries of this request.
5. Wait either for an error response from the server, or for T
seconds (whichever comes first)
6. If no error response is received, after T seconds transmit the
body of the request.
7. If client sees that the connection is closed prematurely,
repeat from step 1 until the request is accepted, an error
response is received, or the user becomes impatient and
terminates the retry process.

Si en algún punto se recibe un estado de error, el cliente

 - SHOULD NOT continue and
- SHOULD close the connection if it has not completed sending the
request message.

Gotchas:

1. Eso es lo que la especificación dice que los navegadores DEBEN hacer. ¿Quién sabe qué hacen los navegadores REALMENTE en este caso? Yo no. Tendrá que hacer algunas pruebas.
2. La especificación hace una mención específica de que este comportamiento solo se aplica " si el cliente no está conectado directamente a un servidor de origen HTTP / 1.1 ". Eso parece un requisito realmente extraño, lo que en la práctica significa que es posible que deba falsificar los encabezados de respuesta del servidor para pretender que es un servidor proxy o HTTP / 1.0.
3. Ciertos protocolos intermedios como fast-cgi pueden no activar su script hasta que la solicitud esté completa. En este caso, realmente necesitará un servidor de socket de bajo nivel real.
4. Todo este proceso es complicado y complicado y puede que ni siquiera funcione. Sería mejor usar AJAX en mi opinión. Sin embargo, usted preguntó si podría hacerse sin JS.